You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -357,11 +357,11 @@ When using standard Vue without a build step and mounting to in-DOM templates, i
357
357
- We have to ship the Vue template compiler to the browser (13kb extra size)
358
358
- The compiler will have to retrieve the template string from already instantiated DOM
359
359
- The compiler then compiles the string into a JavaScript render function
360
-
- Vue then replaces existing DOM templates with new DOM generated from the render funciton.
360
+
- Vue then replaces existing DOM templates with new DOM generated from the render function.
361
361
362
362
`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.
363
363
364
-
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 abstrations. However as you can probably tell, these capabilities are rarely needed in the context of progressive enhancement.
364
+
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.
0 commit comments