Combining Form and Function: Static Types for JQuery Programs

Lerner, Benjamin S.; Elberty, Liam; Li, Jincheng; Krishnamurthi, Shriram

doi:10.1007/978-3-642-39038-8_4

Cited by 17 publications

(15 citation statements)

References 15 publications

(17 reference statements)

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Lerner et al [20] propose a system for type checking programs that use JQuery, a very sophisticated Javascript framework. The proposed type system has special support for JQuery's abstractions, making it quite effective in that domain.…”

Section: Related Workmentioning

confidence: 99%

Just-in-time static type checking for dynamic languages

Ren

Foster

2016

SIGPLAN Not.

View full text Add to dashboard Cite

Dynamic languages such as Ruby, Python, and JavaScript have many compelling benefits, but the lack of static types means subtle errors can remain latent in code for a long time. While many researchers have developed various systems to bring some of the benefits of static types to dynamic languages, prior approaches have trouble dealing with metaprogramming, which generates code as the program executes. In this paper, we propose Hummingbird, a new system that uses a novel technique, just-in-time static type checking, to type check Ruby code even in the presence of metaprogramming. In Hummingbird, method type signatures are gathered dynamically at run-time, as those methods are created. When a method is called, Hummingbird statically type checks the method body against current type signatures. Thus, Hummingbird provides thorough static checks on a per-method basis, while also allowing arbitrarily complex metaprogramming. For performance, Hummingbird memoizes the static type checking pass, invalidating cached checks only if necessary. We formalize Hummingbird using a core, Ruby-like language and prove it sound. To evaluate Hummingbird, we applied it to six apps, including three that use Ruby on Rails, a powerful framework that relies heavily on metaprogramming. We found that all apps typecheck successfully using Hummingbird, and that Hummingbird's performance overhead is reasonable. We applied Hummingbird to earlier versions of one Rails app and found several type errors that had been introduced and then fixed. Lastly, we demonstrate using Hummingbird in Rails development mode to typecheck an app as live updates are applied to it.

show abstract

Section: Related Workmentioning

confidence: 99%

Just-in-time static type checking for dynamic languages

Ren

Foster

2016

SIGPLAN Not.

View full text Add to dashboard Cite

show abstract

“…JQuery Lerner et al [8] examine web programs written using the jQuery library. JQuery provides a higher-level A P I for selecting a set of document elements, navigating from a current set of elements to a new set, and then uniformly manipulating those selected elements in various ways.…”

Section: Violations Of Private Browsing In Extensionsmentioning

confidence: 99%

“…Additionally, we overrode two existing type constructors to enable them to use multiplicities. The types-definition module for the JQuery type system is (see [8] for the meaning of these constructions) The jQuery type system is approximately 5,770LOC (including the 1,600LOC of Bare boilerplate), and includes functionality (e.g., a decision procedure for CSS selectors) that integrates smoothly into the Base type system. Again, most Base functionality was directly reused, without any changes.…”

Section: Example: Adding New Kindsmentioning

confidence: 99%

“…Such precision may or may not be needed, depending on the analysis, and the choice need not be hard-coded into the type system itself. We have used this flexibility as a form of progressive typing [16], to provide a set of guarantees of varying precision when analyzing jQuery programs [8]. • Assigning a type to the global object becomes markedly easier.…”

Section: Explicit External Environment Definitionsmentioning

confidence: 99%

See 1 more Smart Citation

TeJaS

Lerner

Politz

Guha

et al. 2013

Proceedings of the 9th Symposium on Dynamic Languages

Self Cite

View full text Add to dashboard Cite

JavaScript programs vary widely in functionality, complexity, and use, and analyses of these programs must accommodate such variations. Type-based analyses are typically the simplest such analyses, but due to the language's subtle idioms and many application-specific needs-such as ensuring general-purpose type correctness, security properties, or proper library usage-we have found that a single type system does not suffice for all purposes. However, these varied uses still share many reusable common elements.In this paper we present TeJaS, a framework for building type systems for JavaScript. TeJaS has been engineered modularly to encourage experimentation. Its initial type environment is reified, to admit easy modeling of the various execution contexts of JavaScript programs, and its type language and typing rules are extensible, to enable variations of the type system to be constructed easily.The paper presents the base TeJaS type system, which performs traditional type-checking for JavaScript. Because JavaScript demands complex types, we explain several design decisions to improve user ergonomics. We then describe TeJaS's modular structure, and illustrate it by reconstructing the essence of a very different type system for JavaScript. Systems built from TeJaS have been applied to several real-world, third-party JavaScript programs.There is a venerable line of research on retrofitting type systems onto previously "untyped" languages, with Morris's seminal dissertation [11] an early example. In practice, these languages are not actually free of types; rather, all type discrimination is performed by primitive operations at runtime. A common practice for retrofitting type systems has been to identify the resulting set of run-time errors and try to eliminate them statically. For instance, Smalltalk type systems [1, 22] focused on eliminating message-not-found errors, and Soft Scheme [25] addressed the wide range of Scheme dynamic errors. Identifying run-time errors and catching them statically can be viewed as the design principle for retrofitted type systems.Unfortunately, this principle is rather difficult to apply to JavaScript (JS), because there are so few actual run-time errors. 1 In this, JS inherits the forgiving mentality of the browser environment where it was born; instead of flagging errors and halting execution, it simply continues running. As a result, operations that in other languages might reasonably be expected to generate errors do not in JS: subtracting one string from another, accessing an array outside its bounds, reading and writing non-existent fields, calling functions with the wrong number of arguments, etc.Obviously, every one of these operations has a welldefined semantics in JS (usually, ironically, involving the value undefined). Therefore, it becomes a purpose-specific judgment call whether or not these should be considered static type errors. If the purpose is to enforce a strict, Javalike programming style, they should probably all be considered errors. If, in contrast, the goal is ...

show abstract

“…The current state of the art is well surveyed by Andreasen and Møller [9], with the main tools in the field being WALA [50,54] and TAJS [9,28,27]. These tools (and others) provide traditional static analysis frameworks encompassing features such as points-to [26,54] and determinacy analysis [9,50], type inference [33,28] and security properties [23,24]. The modelling of the HTML DOM is generally treated as part of the heap abstraction [27,24] and thus the tree structure is not precisely tracked.…”

Section: Introductionmentioning

confidence: 99%

Detecting redundant CSS rules in HTML5 applications: a tree rewriting approach

Hague

Lin

Ong

2015

Proceedings of the 2015 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applicatio

View full text Add to dashboard Cite

HTML5 applications normally have a large set of CSS (Cascading Style Sheets) rules for data display. Each CSS rule consists of a node selector and a declaration block (which assigns values to selected nodes' display attributes). As web applications evolve, maintaining CSS files can easily become problematic. Some CSS rules will be replaced by new ones, but these obsolete (hence redundant) CSS rules often remain in the applications. Not only does this "bloat" the applications -increasing the bandwidth requirement -but it also significantly increases web browsers' processing time. Most works on detecting redundant CSS rules in HTML5 applications do not consider the dynamic behaviors of HTML5 (specified in JavaScript); in fact, the only proposed method that takes these into account is dynamic analysis, which cannot soundly prove redundancy of CSS rules. In this paper, we introduce an abstraction of HTML5 applications based on monotonic tree-rewriting and study its "redundancy problem". We establish the precise complexity of the problem and various subproblems of practical importance (ranging from P to EXP). In particular, our algorithm relies on an efficient reduction to an analysis of symbolic pushdown systems (for which highly optimised solvers are available), which yields a fast method for checking redundancy in practice. We implemented our algorithm and demonstrated its efficacy in detecting redundant CSS rules in HTML5 applications.

show abstract

Combining Form and Function: Static Types for JQuery Programs

Cited by 17 publications

References 15 publications

Just-in-time static type checking for dynamic languages

Just-in-time static type checking for dynamic languages

TeJaS

Detecting redundant CSS rules in HTML5 applications: a tree rewriting approach

Contact Info

Product

Resources

About