Web Programming Languages Overview

Transcription

1 Web Programming Languages Overview Thomas Powell

2 Web Programming in Context

3 Web Programming Toolbox ActiveX Controls Java Applets Client Side Helper Applications Netscape Plug-ins Scripting Languages * JavaScript * VBScript CGI scripts and programs Server API Programs * ISAPI * NSAPI * Apache Modules Java Servlets Server Side Server-side scripting * Active Server Pages (ASP) * ColdFusion * PHP

4 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

5 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 Idea: Need more glue Document Object Model idea

6 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 Idea: Network protocols in the language directly or easily added

7 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

8 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 Is <if> really any less powerful than if?

9 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

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

11 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

12 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

13 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

14 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

15 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) Current attack plan: IDE, partnership with PHP, etc.

16 New Directions? Rebol Rebol( REBOL is the first messaging language designed specifically for distributed Internet applications and data exchange across all devices. Protocols built-in read Read a Web page write/binary %logo.gif read/binary Fetched and saved an image send [email protected] read Fetched a page and ed to myself

17 New Directions: Rebol Contd. Link checking spider example Shows good markup and networking support Downsides syntax Client-side issues not really addressed properly popularity

18 New Directions: Water Water( XML oriented programming language Hmmm seen this before Tag oriented language Lofty goals Desire to intermix Java, XML, and content cleanly Web services focus Easy integration into HTML/XML templates Very new and not understood Maybe be more marketing than anything

19 New Directions: Super Client Side Macromedia ( 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 ( Pretty similar to Macromedia approach Curl ( Of course all these loose out to AJAX which is the market leader but yet we now have concerns Integration with the server-side! Browser compatibility concerns well beyond what we did before

20 Conclusions No clear winner other than what we have to do tag soup + JavaScript + server side + etc. Can t force developers to embrace new platforms that easily Web sites as legacy apps already! Web programming is pretty hard because it is a messy intersection of content, presentation, logic, and the network Infrastructure improvements will help at the network level but still need to address planning and development of Web apps (see you in 134, 135,etc.)