|
1 | | -# Forget The Build Step: A Browser-Native Workbench For JSX + CSS |
| 1 | +# Forget The Build Step: A Browser-Native Editor For JSX + CSS |
2 | 2 |
|
3 | | -Frontend tooling has become incredibly capable. |
| 3 | +Frontend tooling is incredibly capable. |
4 | 4 |
|
5 | | -It has also become very heavy. |
| 5 | +It is also often front-loaded. |
6 | 6 |
|
7 | | -For many UI experiments, the first thing you do is not write code. You install dependencies, run a dev server, wait for transforms, and only then start iterating. |
| 7 | +For many UI ideas, the first thing you do is not write code. You install, |
| 8 | +configure, and wait. The creative loop starts late. |
8 | 9 |
|
9 | | -I wanted to try a different baseline: |
| 10 | +[@knighted/develop](https://github.com/knightedcodemonkey/develop) is built |
| 11 | +for a different default: fast prototyping from anywhere you can open a browser. |
10 | 12 |
|
11 | | -What if the browser is the dev environment? |
12 | | - |
13 | | -That idea became [@knighted/develop](https://github.com/knightedcodemonkey/develop). |
14 | | - |
15 | | -It is a lightweight in-browser UI component workbench built to showcase [@knighted/jsx](https://github.com/knightedcodemonkey/jsx) and [@knighted/css](https://github.com/knightedcodemonkey/css), with dependencies delivered over CDN ESM instead of requiring a local build step in the inner loop. |
| 13 | +It is a browser-native editor/workbench for |
| 14 | +[@knighted/jsx](https://github.com/knightedcodemonkey/jsx) and |
| 15 | +[@knighted/css](https://github.com/knightedcodemonkey/css), delivered through |
| 16 | +CDN ESM with mode-aware loading. |
16 | 17 |
|
17 | 18 | ## The Loop, In Practice |
18 | 19 |
|
19 | | -Open a page, write JSX and styles, switch rendering/style modes, run lint/typecheck, and see results immediately. |
| 20 | +Open the app, edit multiple files in dynamic tabs, switch render/style modes, |
| 21 | +run lint/type diagnostics, and preview instantly. |
20 | 22 |
|
21 | | -No local bundler needed for that loop. |
| 23 | +No local bundler is required for that inner loop. |
22 | 24 |
|
23 | | -## What Makes It Fun To Use |
24 | | - |
25 | | -The app is intentionally practical, not just a demo shell: |
| 25 | +## What The App Gives You |
26 | 26 |
|
| 27 | +- Dynamic tabbed editing (add, rename, remove, and protect required entry tabs) |
27 | 28 | - Render mode switch: DOM or React |
28 | 29 | - Style mode switch: CSS, CSS Modules, Less, Sass |
29 | | -- Live preview with ShadowRoot toggle |
30 | | -- In-browser lint and type diagnostics |
31 | | -- Diagnostics drawer with jump-to-line navigation (mouse or keyboard) |
| 30 | +- Live preview with iframe-isolated style encapsulation |
| 31 | +- In-browser lint and type diagnostics with jump-to-source navigation |
| 32 | +- GitHub-connected workflows for Open PR and Push Commit |
| 33 | +- AI chat with tab-aware edit proposals and explicit apply/undo controls |
32 | 34 |
|
33 | | -So it is not only "can this compile?" It is closer to "can I actually iterate on a component quickly?" |
| 35 | +This is not only "can this compile?" It is about shipping the whole iteration |
| 36 | +loop in one place: edit, validate, preview, sync, and refine. |
34 | 37 |
|
35 | 38 | ## Why `@knighted/jsx` + `@knighted/css` Matter Here |
36 | 39 |
|
37 | | -`@knighted/develop` is primarily a showcase app. |
38 | | - |
39 | | -It demonstrates how these libraries behave in a real authoring environment: |
| 40 | +The app demonstrates both libraries in realistic authoring conditions: |
40 | 41 |
|
41 | | -- `@knighted/jsx` gives you a direct path from JSX to rendered output, including DOM-first workflows. |
42 | | -- `@knighted/css` handles modern style pipelines in-browser, including Modules/Less/Sass. |
| 42 | +- `@knighted/jsx` provides a direct path from JSX to rendered output, |
| 43 | + including DOM-first workflows. |
| 44 | +- `@knighted/css` handles modern browser-side style compilation, |
| 45 | + including Modules/Less/Sass modes. |
43 | 46 |
|
44 | | -Using both together in one interface makes the bigger point obvious: modern browsers can do much more of the compile/authoring cycle than we usually ask them to. |
| 47 | +Together they show how much of the authoring cycle modern browsers can run |
| 48 | +directly. |
45 | 49 |
|
46 | | -## "Compiler-as-a-Service" Without A Backend Build Farm |
| 50 | +## "Compiler-as-a-Service" Without A Build Farm |
47 | 51 |
|
48 | 52 | In this project, Compiler-as-a-Service means: |
49 | 53 |
|
50 | | -- CDN handles module and WASM delivery. |
51 | | -- The browser tab does the actual compile, lint, typecheck, and render work. |
| 54 | +- CDN delivers modules and WASM artifacts. |
| 55 | +- The browser session performs compile, lint, typecheck, render, and editor |
| 56 | + interactions locally. |
52 | 57 |
|
53 | | -It is service-oriented distribution, local execution. |
| 58 | +It is service-oriented distribution with local execution. |
54 | 59 |
|
55 | | -And because loading is mode-aware, you only pay for what you use. If you never touch Sass, you never load Sass. |
| 60 | +Mode-aware loading keeps costs aligned to usage: if you do not use Sass, |
| 61 | +Sass does not load. |
56 | 62 |
|
57 | 63 | ## Why This Matters |
58 | 64 |
|
59 | | -This is not trying to replace production pipelines. |
| 65 | +This does not replace production pipelines. |
60 | 66 |
|
61 | | -It is about lowering the cost of exploration. |
| 67 | +It lowers the cost of exploration while preserving enough workflow surface to |
| 68 | +be useful for real component work. |
62 | 69 |
|
63 | | -When the setup tax drops, you try more ideas. When feedback is instant, you discover faster. And when the browser is the platform, sharing a repro can be as easy as sharing a URL. |
| 70 | +When setup friction drops, teams try more ideas. When feedback is immediate, |
| 71 | +they converge faster. When browser-native workspaces can sync to GitHub and |
| 72 | +carry chat-assisted edit proposals, collaboration is lighter too. |
64 | 73 |
|
65 | | -For prototyping and component iteration, that is a meaningful shift. |
| 74 | +For prototyping and component development, that is a meaningful shift. |
66 | 75 |
|
67 | 76 | ## Try It |
68 | 77 |
|
69 | 78 | - Live workbench: https://knightedcodemonkey.github.io/develop/ |
70 | 79 | - Source: https://github.com/knightedcodemonkey/develop |
71 | 80 |
|
72 | | -If you are curious, start by toggling: |
| 81 | +If you want a fast product tour, try this sequence: |
73 | 82 |
|
74 | | -1. DOM -> React render mode |
75 | | -2. CSS -> Modules -> Less -> Sass style mode |
76 | | -3. ShadowRoot on/off |
| 83 | +1. Add a new tab, rename it, and make an edit. |
| 84 | +2. Toggle DOM -> React render mode. |
| 85 | +3. Toggle CSS -> Modules -> Less -> Sass style mode. |
| 86 | +4. Open diagnostics and jump to a reported line. |
| 87 | +5. Connect BYOT (Bring Your Own Token) by adding a GitHub personal access token, then run Open PR / Push Commit. |
| 88 | +6. Ask chat for a targeted tab update, then apply it. |
77 | 89 |
|
78 | | -That sequence tells the story better than any architecture diagram. |
| 90 | +That flow tells the product story better than any architecture diagram. |
0 commit comments