Web Programming Toolbox
Server-side scripting
* Active Server Pages (ASP) * ColdFusion * PHP Scripting Languages * JavaScript * VBScript Java Servlets Java Applets ActiveX Controls
Server API Programs * ISAPI
* NSAPI
* Apache Modules Netscape Plug-ins
CGI scripts and programs Helper Applications
Server Side Client Side
Why do we need Web oriented PLs?
• There are numerous reasons that the Web is
motivating a change in Programming
– “too many moving parts”
– developer education background
– Network, etc.
• The goal is not simply to create a single best of
breed Web language
– Historically this “do everything” language has not
done well and ended up doing nothing
– However, we do need to address some of the
problems
Problem 1: Too Many Moving Parts
• A Web application has too many things that can go
wrong
– First it is a client/server programming environment with significant network issues (see later slide)
– Second we find a multitude of client and server-side technologies used in a typical Web project
• Example: HTML/XHTML, CSS, JavaScript, some plug-ins and Active on client-side with Web server with PHP scripts, a database and maybe some Web server modules on the server-side
– Too many skill sets, rough edges between the technologies and interdependency problems that are not well understood
• Example: The HTML compression problem example
Problem 2: The Network
• As a client-server programming environment network
effects (latency, outage, etc.) can pretty much ruin our
“Web programs” at least for a moment
– The Internet using TCP/IP doesn’t guarantee end-to-end transmission times
• Real time follies
– Many hops = many points of failure
• Edge service idea -> introduces replication problems
– Simple ideas hit you left and right basic example with JavaScript
• <script> tag vs <script src=“”> external scripts • Transitory error due to load time problems
– Idea: Network level exception handling
Problem 3: Security
• Given that we are talking about a public network you
are never sure what end users are going to do and what
they might send you
– Users are not to be trusted
– Form overloads, URL attacks, etc.
• We need to make security part of the application
development process not something we add on at the
end
• Idea: positive model security
• Idea: trust or lack of trust in the input/output aspect of
the language
Problem 4: Content Concerns
• Like it or not Web programs are very much about
content in fact one might argue that content is
now more important than ever
– Most programmers and CS profs sell content and
presentation short
– HTML, XHTML, XML, CSS and other presentation level
technologies have to be mixed in and it makes a big
mess
• Is that code in my template or is the template in my code? • Rise of server and client scripting languages which intermix
into markup languages easily
Problem 5: Multiple Platforms and Presentations
• How do you target to multiple browsers and
devices with different computing and display
possibilities?
– Ultimate portability problem
• The Java applet promise undelivered
– Adaptive technologies
– The fallacy of the ultimate transcoder
– This is a very hard problem and something that is
being worked on at UCSD
Problem 6: Developer Knowledge
• There are more of them then there are of us
– How many programmers really are formally trained?
– What happened to the big productivity gains we
should get from OOP?
– What kind of learning curve do we face with OOP,
Java, .NET?
• Job security or business stupidity?
– The lessons of Visual Basic
– The rise of ColdFusion, PHP, etc.
• Idea: Simplicity makes sense but is often filled
with danger (e.g. typing in JavaScript)
Other environmental issues
• Users still have too much control and can mess
you up on purpose or on accident
– I’m anti-view source!
– Browser preferences fun
– Where’s install shield for the Web!?
• Ridiculous time and cost restrictions
– .COM boom and hangover effects create failure
guaranteed projects
• Much of this will come with time as the Web
grows up and may not address by a part of a
language, but some aspects may be included
Web Language Examples
• Java
– On the right track but promise not delivered
• Moving parts – good• Performance issues - so – so / Pass • Security looks reasonable - Pass • Portability reasonable - so - so
– VM incompatability problems • Networking interaction – so-so • Non-skilled developer – failure
– Proof: what’s JSP all about • Content issue - failure
Web Language Examples
• JavaScript
– Originally not designed to do what it is doing now – Moving parts – fail at worst / so-so at best
• HTML / CSS / DOM troubles
– Networking – better with AJAX but need to engineer your own extra stuff so fail
– Content interaction – pass
– Developer issue – so-so (easy and hard) – Security – not so good
– Portability – surprisingly ok
– Issues: just client-side, object model and programming in the large, content protection
Web Language Examples
• PHP / ColdFusion / Simple Server-side Scripting
– Portability – pretty good– Network – pretty good, but could be better
– Security – no better or worse than most other langs - careless programming problems and no built-in help for developer
– Content integration – pretty good - can be done well but can get messy
– Developer issues – good - interestingly high productivity with these languages and uptake with novice programmers, downside some large scale system concerns
– Moving parts – Fail
– Issues: Large language design problem, standards/syntax issue, lack of solid OOP foundation vs. use in big sites, just server-side, scalability concerns
Web Languages Contd.
• ASP.NET and J2EE platform provide the appropriate
large system building framework
• Both platforms try to address the speed concerns that
face the parsed-template scripting languages with a
compile to IL or make a ‘server module’ approach.
– Side-effect of portability tends to be a non-issue in any
environment other than very large heterogeneous enterprise
• Client-side is still problematic
– Both attempt to encapsulate some scripting and UI logic in components
• Both environments suffer from complexity problem
locking out smaller sites from reasonable use as well as
causing some issues with rapid development (see Ruby)
New Directions? Rebol
• Rebol (
www.rebol.com
)
– “REBOL is the first messaging language designed
specifically for distributed Internet applications and
data exchange across all devices.”
– Protocols built-in
• read http://www.pint.com/index.html Read a Web page
write/binary %logo.gif read/binary
http://www.pint.com/images/logo.gif
Fetched and saved an image
send [email protected] read http://www.news.com
New Directions: Rebol Contd.
• Link checking spider example
–
http://www.reboltech.com/library/html/site-check.html
• Shows good markup and networking support
• Downsides
– syntax
– Client-side issues not really addressed properly
– popularity
New Directions: Water
• Water (
http://www.waterlang.org/
)
– XML oriented programming language
• Hmmm…seen this before Tag oriented language
• http://www.waterlang.org/doc/tutorial_fast_intro.html
– Lofty goals
• Desire to intermix Java, XML, and content cleanly • Web services focus
• Easy integration into HTML/XML templates
– Very new and not understood
New Directions: Super Client Side
• Macromedia (www.macromedia.com)
– ColdFusion MX & Flash = Rich Internet Applications – Flash player with XML data passing over the network
• Upside: Flash player • Downside: Flash player
• Constant: ActionScript = JavaScript
• Lazlo (
http://www.laszlosystems.com/
)
– Pretty similar to Macromedia approach• Curl (
http://www.curl.com
)
• Of course all these loose out to AJAX which is the
market leader but yet we now have concerns
– Integration with the server-side!
