[TriLUG] Javascript.. why?

[Tim Jowers]

Dude,

Disabling JavaScript is a relic. You either run JavaScript and/or
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

      JavaScript or Flash?

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
success is IBM's support. They support JavaScript frameworks such as
jMaki via their Snippet View in RAD7. Also, JavaScript now has some
decent tools and is closing the UI technology gap on Flash/Flex like a
tempest.

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).

For another reason, JavaScript is more standard that Flash. That is,
if I write a portal solution and a hugeco wants to plug it into their
website seamlessly, JavaScript/DHTML/Ajax simply has a lower learning
curve.

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.

But JavaScript frameworks are blowing the top off of it. Most of all,
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
(JavaScript) or some other dynamic and data caching technology. Anyone
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
toward JSON (passing strings which are JavaScript data objects and
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
Flex/Flash.

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
general.

My $.02,
Tim Jowers
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.
CSRF and XSS are some real JavaScript-related security concerns but
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
>> Javascript on web pages these days?
>
> I'm not a fulltime web developer, but I'll be glad to tell you why I used
> JavaScript on 3 Troubleshooters.Com web pages and on all my Paypal buttons...
>
> 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
> to those with old browsers, so I used javascript/css to create the 1 level
> 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
> javascript to create the calculators at
> 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
> level validation was, so I used Javascript to do all calculations on the
> browser.
>
> 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
> knows the computer isn't hung. So, using Javascript, I created Paypal buttons
> 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.
>
> In each of the preceding cases, I used Javascript because it was the easiest
> way, THAT I KNEW OF, to accomplish what I needed accomplished. All pages in
> the Troubleshooters.Com Bookstore have javascript, but outside the Bookstore,
> less than 1 percent of Troubleshooters.Com pages have javascript. Personally
> 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.
>
> SteveT
>
> Steve Litt
> Recession Relief Package
> http://www.recession-relief.US
>
> --
> TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
> TriLUG FAQ  : http://www.trilug.org/wiki/Frequently_Asked_Questions
>