|
1 | | -# DOM Expressions |
2 | | - |
3 | | -[](https://travis-ci.com/ryansolid/dom-expressions) |
4 | | -[](https://coveralls.io/github/ryansolid/dom-expressions?branch=master) |
5 | | -[](https://www.npmjs.com/package/dom-expressions) |
6 | | - |
7 | | - |
8 | | - |
9 | | - |
10 | | -DOM Expressions is a Rendering Runtime for reactive libraries that do fine grained change detection. These libraries rely on concepts like Observables and Signals rather than Lifecycle functions and the Virtual DOM. Standard JSX transformers are not helpful to these libraries as they need to evaluate their expressions in isolation to avoid re-rendering unnecessary parts of the DOM. |
11 | | - |
12 | | -This package wraps libraries like KnockoutJS or MobX and use them independent of their current render systems using a small library to render pure DOM expressions. This approach has been proven to be incredibly fast, dominating the highest rankings in the [JS Framework Benchmark](https://github.com/krausest/js-framework-benchmark). |
13 | | - |
14 | | -It is designed to be used with a companion render API. Currently there is a JSX Babel Plugin, and Tagged Template Literals, and HyperScript runtime APIs. Most developers will not use this package directly. It is intended to help author your own Reactive Libraries and not to be used directly in projects. |
15 | | - |
16 | | -## Example Implementations |
17 | | -* [Solid](https://github.com/ryansolid/solid): A declarative JavaScript library for building user interfaces. |
18 | | -* [mobx-jsx](https://github.com/ryansolid/mobx-jsx): Ever wondered how much more performant MobX is without React? A lot. |
19 | | -* [ko-jsx](https://github.com/ryansolid/ko-jsx): Knockout JS with JSX rendering. |
20 | | -* [s-jsx](https://github.com/ryansolid/s-jsx): Testbed for trying new techniques in the fine grained space. |
21 | | - |
22 | | -## Runtime Generator |
23 | | - |
24 | | -Dom Expressions is designed to allow the runtime to be tree shakeable by generating a special version ahead of time so static module analysis provided by your bundler can do it's thing. |
25 | | - |
26 | | -To create runtime first install: |
27 | | -```sh |
28 | | -> npm i --save-dev dom-expressions |
29 | | -``` |
30 | | -You must provide symbols to create the final js file and the output path. We do this through a dom-expressions.config.js in your project root. |
31 | | - |
32 | | -```js |
33 | | -module.exports = { |
34 | | - output: 'path-to-output/filename.js', |
35 | | - variables: { |
36 | | - imports: [ `import wrap from 's-js'` ] |
37 | | - } |
38 | | -} |
39 | | -``` |
40 | | - |
41 | | -These symbols should reference an observable API with the following functionality: |
42 | | - |
43 | | -### wrap(fn) : void |
44 | | - |
45 | | -This is used to wrap all expressions in computations. Your wrap method is expected to call fn with the previously evaluated value if the arity is 1 to allow for reducing computations. |
46 | | - |
47 | | -Then you run the cli command: |
48 | | -```sh |
49 | | -> dom-expressions |
50 | | -``` |
51 | | - |
52 | | -There are more advanced options to support a Context API. Look at the examples. Still experimental and will document as it stabilizes. |
53 | | - |
54 | | -## Runtime Renderers |
55 | | - |
56 | | -Once you have generated a runtime it can be used with companion render APIs: |
57 | | - |
58 | | -### JSX |
59 | | - |
60 | | -[Babel Plugin JSX DOM Expressions](https://github.com/ryansolid/babel-plugin-jsx-dom-expressions) is by far the best way to use this library. Pre-compilation lends to the best performance since the whole template can be analyzed and optimal compiled into the most performant JavaScript. This allows for not only the most performant code, but the cleanest and the smallest. |
61 | | - |
62 | | -### Tagged Template |
63 | | - |
64 | | -If precompilation is not an option Tagged Template Literals are the next best thing. [Lit DOM Expressions](https://github.com/ryansolid/lit-dom-expressions) provides a similar experience to the JSX, compiling templates at runtime into similar code on first run. This option is the largest in size and memory usage but it keeps most of the performance and syntax from the JSX version. |
65 | | - |
66 | | -### HyperScript |
67 | | - |
68 | | -While not as performant as the other options this library provides a mechanism to expose a HyperScript version. [Hyper DOM Expressions](https://github.com/ryansolid/hyper-dom-expressions) offers the greatest flexibility working with existing tooling for HyperScript and enables pure JS DSLs. |
69 | | - |
70 | | -## Work in Progress |
71 | | - |
| 1 | +# DOM Expressions |
| 2 | + |
| 3 | +[](https://travis-ci.com/ryansolid/dom-expressions) |
| 4 | +[](https://coveralls.io/github/ryansolid/dom-expressions?branch=master) |
| 5 | +[](https://www.npmjs.com/package/dom-expressions) |
| 6 | + |
| 7 | + |
| 8 | + |
| 9 | + |
| 10 | +DOM Expressions is a Rendering Runtime for reactive libraries that do fine grained change detection. These libraries rely on concepts like Observables and Signals rather than Lifecycle functions and the Virtual DOM. Standard JSX transformers are not helpful to these libraries as they need to evaluate their expressions in isolation to avoid re-rendering unnecessary parts of the DOM. |
| 11 | + |
| 12 | +This package wraps libraries like KnockoutJS or MobX and use them independent of their current render systems using a small library to render pure DOM expressions. This approach has been proven to be incredibly fast, dominating the highest rankings in the [JS Framework Benchmark](https://github.com/krausest/js-framework-benchmark). |
| 13 | + |
| 14 | +It is designed to be used with a companion render API. Currently there is a JSX Babel Plugin, and Tagged Template Literals, and HyperScript runtime APIs. Most developers will not use this package directly. It is intended to help author your own Reactive Libraries and not to be used directly in projects. |
| 15 | + |
| 16 | +## Example Implementations |
| 17 | +* [Solid](https://github.com/ryansolid/solid): A declarative JavaScript library for building user interfaces. |
| 18 | +* [mobx-jsx](https://github.com/ryansolid/mobx-jsx): Ever wondered how much more performant MobX is without React? A lot. |
| 19 | +* [ko-jsx](https://github.com/ryansolid/ko-jsx): Knockout JS with JSX rendering. |
| 20 | +* [s-jsx](https://github.com/ryansolid/s-jsx): Testbed for trying new techniques in the fine grained space. |
| 21 | + |
| 22 | +## Runtime Generator |
| 23 | + |
| 24 | +Dom Expressions is designed to allow the runtime to be tree shakeable by generating a special version ahead of time so static module analysis provided by your bundler can do it's thing. |
| 25 | + |
| 26 | +To create runtime first install: |
| 27 | +```sh |
| 28 | +> npm i --save-dev dom-expressions |
| 29 | +``` |
| 30 | +You must provide symbols to create the final js file and the output path. We do this through a dom-expressions.config.js in your project root. |
| 31 | + |
| 32 | +```js |
| 33 | +module.exports = { |
| 34 | + output: 'path-to-output/filename.js', |
| 35 | + variables: { |
| 36 | + imports: [ `import wrap from 's-js'` ] |
| 37 | + } |
| 38 | +} |
| 39 | +``` |
| 40 | + |
| 41 | +These symbols should reference an observable API with the following functionality: |
| 42 | + |
| 43 | +### wrap(fn) : void |
| 44 | + |
| 45 | +This is used to wrap all expressions in computations. Your wrap method is expected to call fn with the previously evaluated value if the arity is 1 to allow for reducing computations. |
| 46 | + |
| 47 | +Then you run the cli command: |
| 48 | +```sh |
| 49 | +> dom-expressions |
| 50 | +``` |
| 51 | + |
| 52 | +There are more advanced options to support a Context API. Look at the examples. Still experimental and will document as it stabilizes. |
| 53 | + |
| 54 | +## Runtime Renderers |
| 55 | + |
| 56 | +Once you have generated a runtime it can be used with companion render APIs: |
| 57 | + |
| 58 | +### JSX |
| 59 | + |
| 60 | +[Babel Plugin JSX DOM Expressions](https://github.com/ryansolid/babel-plugin-jsx-dom-expressions) is by far the best way to use this library. Pre-compilation lends to the best performance since the whole template can be analyzed and optimal compiled into the most performant JavaScript. This allows for not only the most performant code, but the cleanest and the smallest. |
| 61 | + |
| 62 | +### Tagged Template |
| 63 | + |
| 64 | +If precompilation is not an option Tagged Template Literals are the next best thing. [Lit DOM Expressions](https://github.com/ryansolid/lit-dom-expressions) provides a similar experience to the JSX, compiling templates at runtime into similar code on first run. This option is the largest in size and memory usage but it keeps most of the performance and syntax from the JSX version. |
| 65 | + |
| 66 | +### HyperScript |
| 67 | + |
| 68 | +While not as performant as the other options this library provides a mechanism to expose a HyperScript version. [Hyper DOM Expressions](https://github.com/ryansolid/hyper-dom-expressions) offers the greatest flexibility working with existing tooling for HyperScript and enables pure JS DSLs. |
| 69 | + |
| 70 | +## Work in Progress |
| 71 | + |
72 | 72 | This is still a work in progress. My goal here is to better understand and generalize this approach to provide non Virtual DOM alternatives to developing web applications. |
0 commit comments