From 126d32a05e2ed0254b146c7e0679f3432dff7cbb Mon Sep 17 00:00:00 2001 From: Simon He <57086651+Simon-He95@users.noreply.github.com> Date: Thu, 3 Nov 2022 00:29:51 +0800 Subject: [PATCH 1/2] chore: typo --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index efa2241..6f1ba6c 100644 --- a/README.md +++ b/README.md @@ -92,7 +92,7 @@ The `createApp` function accepts a data object that serves as the root scope for ``` -Note `v-scope` doesn't need to have a value here and simply serves as a hint for `petite-vue` to process the element. +Note: `v-scope` doesn't need to have a value here and simply serves as a hint for `petite-vue` to process the element. ### Explicit Mount Target @@ -369,7 +369,7 @@ When using standard Vue without a build step and mounting to in-DOM templates, i - The compiler then compiles the string into a JavaScript render function - Vue then replaces existing DOM templates with new DOM generated from the render function. -`petite-vue` avoids all this overhead by walking the existing DOM and attaching fine-grained reactive effects to the elements directly. The DOM _is_ the template. This means `petite-vue` is much more efficient in progressive enhancement scenarios. +`petite-vue` avoids all this overhead by walking the existing DOM and attaching fine-grained reactive effects to the elements directly. The DOM is the template. This means `petite-vue` is much more efficient in progressive enhancement scenarios. This is also how Vue 1 worked. The trade-off here is that this approach is coupled to the DOM and thus not suitable for platform agnostic rendering or JavaScript SSR. We also lose the ability to work with render functions for advanced abstractions. However as you can probably tell, these capabilities are rarely needed in the context of progressive enhancement. From 572af380e4adf0c97bcced3b0167a1bf77075e93 Mon Sep 17 00:00:00 2001 From: Simon He <57086651+Simon-He95@users.noreply.github.com> Date: Thu, 3 Nov 2022 12:45:33 +0800 Subject: [PATCH 2/2] chore: update --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 6f1ba6c..82db83a 100644 --- a/README.md +++ b/README.md @@ -369,7 +369,7 @@ When using standard Vue without a build step and mounting to in-DOM templates, i - The compiler then compiles the string into a JavaScript render function - Vue then replaces existing DOM templates with new DOM generated from the render function. -`petite-vue` avoids all this overhead by walking the existing DOM and attaching fine-grained reactive effects to the elements directly. The DOM is the template. This means `petite-vue` is much more efficient in progressive enhancement scenarios. +`petite-vue` avoids all this overhead by walking the existing DOM and attaching fine-grained reactive effects to the elements directly. The DOM _is_ the template. This means `petite-vue` is much more efficient in progressive enhancement scenarios. This is also how Vue 1 worked. The trade-off here is that this approach is coupled to the DOM and thus not suitable for platform agnostic rendering or JavaScript SSR. We also lose the ability to work with render functions for advanced abstractions. However as you can probably tell, these capabilities are rarely needed in the context of progressive enhancement.