3.7 KiB
3.7 KiB
%title: Beyond .*Script %author: hellerve %date: 2017-01-15
-> # Beyond .*Script
-> ## Implementing A Language For The Web
-> Veit Heller -> Bachelor examination
-> # Introduction
- JavaScript is the language of the Web
- It is not always the right tool for the job
- Many approaches have been taken to change it to fit the users needs
-> # Introduction
- Mitigations fall into two categories
- Preprocessors
- Transpilers
- Caveat: thin wrapper around JavaScript
-> # Introduction
- zepto-js attempts to build a runtime that is foreign to JavaScript while still being compatible
- Features: Functional, Lisp, Macros, Continuations
-> # Related Work
-> ## Existing Projects
- Roughly two categories: transpilers and abstraction languages
- transpilers: compiles one high level language into another
- GHCJS
- Emscripten
- ClojureScript
- abstraction languages: add features to JavaScript, do not change semantics
- CoffeeScript
- Elm
- PureScript
- transpilers: compiles one high level language into another
-> # Related Work
-> ## Existing Standards
- Lisp pretty well standardized, but conflicting standards
- Scheme was chosen, so Scheme Requests for Implementation are relevant
- Unix: development artifact that affects zepto
-> # Concept Design
-> # System Design
- modifications of zepto for browser necessary
-> # System Design
- web ecosystem
- content delivery
- integration into websites (HTML, CSS, JavaScript, zepto)
-> # System Design
- API availability
- WebGL, WebAudio (through FFI)
- build tools (natively)
-> # Implementation
- Goals:
- be as compatible with zepto as possible
- do not implement features that are inherently not designed for the web
-> # Implementation
-> ## Toolchain
- GHCJS (GHC compiler with JavaScript backend)
- Grunt for task automation
-> # Implementation
-> ## <script>
- enable development experience similar to JavaScript
- also enables loading of assets and external files
- deprecates the zepto
loadkeyword
-> # Implementation
-> ## FFI
- enable working with JavaScript bi-directionally
- simple string-based FFI
- abstraction libraries allow for parsing of results e.g. with JSON
- zepto side through GHCJS quasi-quoting
- JavaScript side through calls to the zepto interpreter object
-> # Implementation
-> ## DOM
- Through the FFI DOM calls were possible
- available through a third-party module
-> # Implementation
-> ## Omissions
- language definitions
- absence of files does not allow for
load
- absence of files does not allow for
- later versions of zepto
- GHC intrinsics to load C and Haskell libraries during runtime
- compiled code not (yet) executable in browser
-> # Evaluation of the Prototype
- zepto is primarily a platform for prototyping
- Usability was measured during an introductory workshop
- Generally favorable feedback, questions mostly around tooling
-> # Evaluation of the Prototype
- Addition of the FFI solves performance problems
- suboptimal, but deemed acceptable for this particular use case
- Features missing affect the compatibility with existing zepto libraries
-> # Evaluation of the Prototype
- marginally slower than zepto reference in most use cases
- much slower than native JavaScript
- calling into FFI for performance optimization still necessary
-> # Summary and Outlook
- zepto-js is as experimental as zepto itself
- with the maturation of zepto and zeps, zepto-js can grow
- tooling still not on par with JavaScript
-> # Summary and Outlook
- since thesis was written:
- compiler backend to JavaScript in zepto (node)
- first stable release of zepto (version 0.9.6)
- zepto-js development stunted
-> # Thank you for listening.
-> I am now ready to take questions.