To postpone indefinitely the decision of platform for JS logic
To help decide on ES6 and Typescript adoption
By supplying a concrete implementation in ES5 to evaluate complexity, cost and risk of implementations in ES5 with i.e. the few simple patterns in prettytype, as compared with implementations in ES6 not fully supported in all platforms, or strongly mediated by libraries or transpilers.
To debunk arguments pro-browserify and pro-transpiler
By showing how multi-platform can be achieved with a much lighter-weigh approach.
To reuse module and prototype patterns and supertypes
To showroom multi-platform module and prototype definitions
Native un-mediated scaffolding
Human-accessible, debuggable code
That a programmer may breakpoint in meaningful, no-magic places, and just step through the initialisations in self-documented, intention-revealing code.
Native most widely supported ES5
ECMAScript 5 JS 1.8.5 March 2011
Multi-platform Module definition and Dependency Injection
The same source code with module definitions and dependency injections can be loaded and executed through the major module definition technologies for the server and the browser, directly and without relying on any library or any source code transformation.
Module definition standards
- angularjs (1.x)
- RequireJS (AMD)
- Server: nodejs all versions from 0.10.x and later
- Browser: Chrome, Firefox,Opera, Safari, edge, headless, Phantom
browserify may also be considered its own module definition standard and platform, because in all its efforts to facilitate portability across platforms and module definition standards, introduces a rich, full-featured toolset and pipeline, not without its own quirks and learning curve. http://browserify.org/
prettytype gets rid of all such machinery, by directly supporting the most popular platforms and module definition standards by just using a few syntactical patterns, as described in the section "Implementations" below, and available in source and test code in GitHub https://github.com/carrascoMDD/prettytype
It is left as an exercise for the curious or motivated, to process prettytype or its re-utilisations through browserify machinery. Potential issues may be, among others: how to ensure that browserify interprets prettytype input code as pertaining to one of its 3 different platform "faces" ? Note that all module definition standards are used in the same code, and static code analysis may reveal to browserify machinery that various/all the supported module definition standards are in use in the code, thus potentially becoming difficult for browserify machinery to perform proper code transformation and assembly.