[TriLUG] Javascript.. why?

[Tim Jowers]

A few JavaScript frameworks for review. E.g. jQuery now does fades,
positioning, and such and has many if not more of the same display
widgets as Flash. (I know "widgets" smacks of the old X terminology
but that's what they are being called. It works.)

Dynarach. commercial (LGPL): http://www.dynarch.com/demos/jscalendar/
Dojo/Dijit: http://docs.dojocampus.org/dijit/form/DateTextBox#examples
jQuery: http://ui.jquery.com/repository/tags/latest/demos/functional/#ui.datepicker
Yahoo UI: http://developer.yahoo.com/yui/examples/calendar/popup.html
Extjs: Commercial. http://extjs.com/deploy/dev/examples/locale/multi-lang.html


These abstract out most of the IE nonstandard implementation so you
can just write to the framework and it will work on the major
browsers. Also, it is REALLY exciting to note the JavaScript engines
are being improved drastically. I think Chrome and FF run like 3 times
faster than the older web browsers. Like I said, this is the area of
innovation. Good things should follow.


Who will win?  jQuery? extjs?  jMaki (facade layer)? YUI?  The third
big question in the industry. I know one major company is using extjs
after having performance issues with DOJO early on and another is
using jQuery after having used Scriptalicious and others.

TimJowers



On Mon, Dec 15, 2008 at 9:54 AM, Tim Jowers <timjowers at gmail.com> wrote:
> 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
>>
>