Talking Points on JavaScript for Software Engineering
Perspective
- Widespread agreement that object technology is effective
- Less agreement that the kind of strict object development environment supported by, for example, Java or Eiffel is desirable
- Systems containing large amounts of JavaScript code are now shipping on the Web
- IMHO, JavaScript is less than ideal for software engineering
- Not statically checkable (either in terms of state-space or concurrency)
- Object-based vs. Object-oriented
- Most obstacles to object-oriented can be overcome
- Still, significant limitations:
- Encapsulation
- "Classless" objects cannot be completely prohibited
- Randomly adding/removing properties to objects
- Polymorphism
- Method overriding cannot cleanly be done with separate methods
- Poses a problem for Javadoc-like documentation generators
- Data types
- The loose typing makes the code hard to read, even when type prefixing is used and data types are respected.
- Impossible to enforce strict typing
- Interfaces
- Can be done, but only "enforced" through a slow run-time process.
- The enforcement routines could be removed for non-development-time situations.
- Events: Cannot prohibit spaghetti-like "callbacks"
- Packaging: Does not mirror the file system, and no enforcable naming convention
- Aspect-oriented programming
- Can be done, but significant run-time and code-clarity issues since JavaScript was not designed for this.
- http://aspectes.tigris.org/
- It could be much worse -- remember some thought that on the Web it would be VBScript!
Origins
- How do Self and C-- add up? JavaScript!
- A hard-to-meet deadline for Brendan at Netscape in the 1990's
- The language's market: Not necessarily software engineers
- Paradox Supreme: The rarified, research facility life of Self, compared to the ubiquity of JavaScript!
- In a paper on Self, its creators wondered if true class inheritance, as distinguished from Self's prototype inheritance, would predominate in software engineering in the future.
- Self and the SmallTalk Community: Killed by Java?
- StrongTalk: The built-in event-basis of SmallTalk with the structured object development provided by Java?
- http://www.strongtalk.org/
- http://www.strongtalk.org/history.html
- Where did that source code come from?
- In early versions of Netscape (version 4, circa 1998, and less), the 'select' html element was implemented as a first-class window object.
- That meant that it could not be hidden by other html elements on the screen.
- Clearly a bug, this was fixed in Netscape 6 around 2000.
- Was present in the early IE browsers that took Netscape's market share.
- Still exists in IE 6
JavaScript Considered
- High power-to-weight ratio!
- As with Self, "The Power of Simplicity".
- Fast start time
- Ability to self-modify the language
- Allows us to do object-oriented software engineering in JavaScript, and implement concepts from other languages, such as binding objects through an event system.
- Property value lookup very slow at high memory load
- Closure overhead
- Machine capabilities now growing -- so is the low weight of JavaScript really such a big advantage anymore?
JavaScript's Future
- EcmaScript 4 Proposal: Adding Structure
- 'strict' option not yet in reference implementation
- Tamarin JIT and Adobe
- A tools strategy by that company, not a platform play with Flash as it may appear?
- Interesting post by Brendan Eich, creator of JavaScript, on Microsoft opposing EcmaScript 4, the proposed new version of JavaScript:
http://weblogs.mozillazine.org/roadmap/archives/2007/11/es4_news_and_opinion.html#more
- The compatibility issue: A corporate "we can't" (make a reliable, interoperable implementation of ES4) from MS?
- MS management's considerations: A competitor to Silverlight and C#?
- Is there a Neutral Ground Solution: A language such as StrongTalk? In reality, it might be Python:
- My guess: It depends on Google and Apple. If they apply their full weight, Microsoft will implement ES4.
