235 lines
4.4 KiB
Markdown
235 lines
4.4 KiB
Markdown
%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
|
|
|
|
---
|
|
|
|
-> # 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
|
|
|
|
-> ## Lisp
|
|
|
|
- simple in terms of syntax
|
|
- expressive
|
|
- very different from JavaScript
|
|
|
|
---
|
|
|
|
-> # Concept Design
|
|
|
|
-> ## zepto
|
|
|
|
- Good grasp on the language and implementation details
|
|
- simple Scheme, yet feature-complete
|
|
- Haskell implementation lends itself well to cross-compilation
|
|
- small code size ensures small JavaScript compilate
|
|
|
|
---
|
|
|
|
-> # Concept Design
|
|
|
|
-> ## Macros & Continuations
|
|
|
|
- features handy, but not present in JavaScript
|
|
- serve as a benchmark for the compiler
|
|
|
|
---
|
|
|
|
-> # Concept Design
|
|
|
|
-> # Ecosystem
|
|
|
|
- the module system
|
|
- ensures identifier uniqueness through namespaces
|
|
- standard library
|
|
- extensive, general-purpose library
|
|
- zeps
|
|
- modern package manager
|
|
|
|
---
|
|
|
|
-> # 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 `load` keyword
|
|
|
|
---
|
|
|
|
-> # 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`
|
|
- 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.
|