├── LICENSE ├── .gitignore └── README.md /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2022 SolidJS Community 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Logs 2 | logs 3 | *.log 4 | npm-debug.log* 5 | yarn-debug.log* 6 | yarn-error.log* 7 | lerna-debug.log* 8 | 9 | # Diagnostic reports (https://nodejs.org/api/report.html) 10 | report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json 11 | 12 | # Runtime data 13 | pids 14 | *.pid 15 | *.seed 16 | *.pid.lock 17 | 18 | # Directory for instrumented libs generated by jscoverage/JSCover 19 | lib-cov 20 | 21 | # Coverage directory used by tools like istanbul 22 | coverage 23 | *.lcov 24 | 25 | # nyc test coverage 26 | .nyc_output 27 | 28 | # Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files) 29 | .grunt 30 | 31 | # Bower dependency directory (https://bower.io/) 32 | bower_components 33 | 34 | # node-waf configuration 35 | .lock-wscript 36 | 37 | # Compiled binary addons (https://nodejs.org/api/addons.html) 38 | build/Release 39 | 40 | # Dependency directories 41 | node_modules/ 42 | jspm_packages/ 43 | 44 | # TypeScript v1 declaration files 45 | typings/ 46 | 47 | # TypeScript cache 48 | *.tsbuildinfo 49 | 50 | # Optional npm cache directory 51 | .npm 52 | 53 | # Optional eslint cache 54 | .eslintcache 55 | 56 | # Microbundle cache 57 | .rpt2_cache/ 58 | .rts2_cache_cjs/ 59 | .rts2_cache_es/ 60 | .rts2_cache_umd/ 61 | 62 | # Optional REPL history 63 | .node_repl_history 64 | 65 | # Output of 'npm pack' 66 | *.tgz 67 | 68 | # Yarn Integrity file 69 | .yarn-integrity 70 | 71 | # dotenv environment variables file 72 | .env 73 | .env.test 74 | 75 | # parcel-bundler cache (https://parceljs.org/) 76 | .cache 77 | 78 | # Next.js build output 79 | .next 80 | 81 | # Nuxt.js build / generate output 82 | .nuxt 83 | dist 84 | 85 | # Gatsby files 86 | .cache/ 87 | # Comment in the public line in if your project uses Gatsby and *not* Next.js 88 | # https://nextjs.org/blog/next-9-1#public-directory-support 89 | # public 90 | 91 | # vuepress build output 92 | .vuepress/dist 93 | 94 | # Serverless directories 95 | .serverless/ 96 | 97 | # FuseBox cache 98 | .fusebox/ 99 | 100 | # DynamoDB Local files 101 | .dynamodb/ 102 | 103 | # TernJS port file 104 | .tern-port 105 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 |

2 | solid-dsl 3 |

4 | 5 | # Solid DSL Experiments 6 | 7 | This library has been created to house experimentation and discussion of current and future DSL related topics. Solid is firmly rooted in JSX and we intend to have it remain with JSX so that it may continue benefiting from the large JSX ecosystem. However this shouldn't stop the community from embarking on explorations relating to augmenting/enhancing and iterating on JSX improvements. 8 | 9 | **Note:** Most of the work on this repo is related to conversations in the [Discussion tab](https://github.com/solidjs-community/solid-dsl/discussions). 10 | 11 | ## Stages 12 | 13 | We'd like to organize this exploration process into 3 general stages: 14 | 15 | 1. `Collect & Summarize` - The first stage will invovle collecting ideas. It's important as a community to tease out the painpoints of current day JSX. This process should summarize all the benefits of adoping new ideas. It should be a wishlist of ideas. 16 | 2. `Explore & Implement` - The second stage will involve exploring and testing the viability of ideas. This may result in additional options 17 | 3. `RFC` - The last stage should be establishing an RFC to publicize and share amongst the broader JSX community. We should collect broad feedback and possibly vote in public on the changes. 18 | 19 | These steps are abitrary but should provide a framework for accomplishing the goal of exploring the potential of working within the context of JSX. 20 | 21 | ## Guidelines 22 | 23 | It's critical that this project have boundaries. For this reason here are some high-level rules and objectives: 24 | 25 | 1. The goal isn't to adopt a DSL for Solid Core to adopt. This will be at core's discretion. 26 | 2. We will not seek to adopt patterns from other frameworks. The goal is to develop a superset of JSX not a Svelte/Vue clone DSL. 27 | 3. Ideas need to be practical and proven with experiments. 28 | 4. Solve painpoints or smooth current "rough edges" that JSX has as identified by the community. 29 | 30 | This project is to be treated experimental and exploratory. Let's keep the dialogue clean, concise and professional. 31 | 32 | ## Details 33 | 34 | Solid's compiler is based on a Babel transformer called [babel-preset-solid](https://www.npmjs.com/package/babel-preset-solid). It's based on the critical work done by Ryan C. on [dom-expressions](https://github.com/ryansolid/dom-expressions) which is the critical piece. A lot of the experiments in this package should aim to build onto these dependencies. Since those are core managed we need to treat them as lower level dependencies if possible or define a way to enhance them progressively. 35 | 36 | ## General Improvements vs Radical 37 | 38 | The risk of a project such as this is that individuals take it as an opportunity to blow the design process out of proportion. The goal of this experiment isn't to re-imagine or rethink reactive DSL in the context of Solid's use. Consider it a progressive enhancement to take Solid and JSX into a future where JSX is simpler. Better yet consider covering edge cases that aren't easily filled by JSX currently 39 | --------------------------------------------------------------------------------