3 ms·

> personally the template-string seems unoffensive & direct enough to me. it's a go at trying to meld html and programming together, and it seems basically fine

by dmix 4y ago

> personally the template-string seems unoffensive & direct enough to me. it's a go at trying to meld html and programming together, and it seems basically fine Then you've never built a large serious production JS frontend using something like Vue. Saying that JS template strings are a sufficient replacement for SFC Vue files or JSX (or any popular templating system) sounds crazy to me. This would depend very heavily on IDE integrations [1] but even then it would be extremely messy and only add more complexity than removing transpliers gain. Sure it's fine for small niche usecases but if it was a serious option it would have been pushed long ago. JS templates have been around for 7yrs now. [1] getting the whole team to just use VSCode is a big ask or getting HTML+Vue formatting/syntax highlighting working across Vim/Webstorm/etc. Then there's losing Prettier + Elint for linting and autoformatting. There's so much tooling lost with template strings,

mythz 4y ago
What you can do in a Vue SFC you can also do in a templated string component, if the component gets too big you can always break it down into smaller components as normal. Sure you can benefit from a smart IDE which understands templated strings, just as they improve the authoring UX for Vue SFC's. The Vue component used for its working CRUD Example is at [1] which is the verbose version, a more capable example [2] with a lot more functionality is available at [2] which uses the new AutoQueryGrid component to reduce the functionality down to 1 line. The point of adopting a traditional Multi Page App approach is that you don't need to build a large serious JS SPA frontend as the separate pages provides natural isolation where you only need to build isolated components for the functionality each page needs which is typically glue code that makes use of external libraries & components. [1] https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/wwwroot/Pages/Bookings.mjs https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/... [2] https://vue-mjs.web-templates.io/bookings-auto https://vue-mjs.web-templates.io/bookings-auto [3] https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/Pages/BookingsAuto.cshtml https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/...
rektide 4y ago
This seems like a case of caring way too much about something that's hardly very different. JSX versus tagged template strings can be incredibly similar to one another. The examples in this article are using vanilla template strings to author raw html, but that only misses a couple of nicities JSX has. There are tagged template string libraries like htm[1] that do include some of the few nicities JSX has, but which are actually compatible with the official language. [1] https://github.com/developit/htm https://github.com/developit/htm
- dmitriid 4y ago
  Define "compatible with the language". Anything you shove into a string and then parse yourself is "compatible with the language". Doesn't make it better or significantly different from systems that do this step earlier.
  - rektide 4y ago
    Compatible with the language seems like a dead obvious concept to me: something you can do with the current TC39 EcmaScript language. Anything you do with JSX isnt compatible with the language. So that makes it worse & significantly different. Diving way into technics, tagged template strings, if called from a function, will have reference equality for the literals array. The optimizations might not be ahead of time, but the net is, even if the tagged template string is inline and single-phase (as opposed to moving your tagged template strings to the top level & having them "compile" & return a function to accept variables/children), there's still a lot of room for reusing the same "compiled"/parsed work.
    - dmitriid 4y ago
      > Compatible with the language seems like a dead obvious concept to me: something you can do with the current TC39 EcmaScript language. Most JS frameworks are written in JS. You can run React, Svelte, Vue etc. directly from the browser without a build step. > Anything you do with JSX isnt compatible with the language. So that makes it worse & significantly different. So, this is an artificial and absolutely arbitrary line that only looks good because you chose it to be so. Also, JS world is probably unique among all programming languages with such aversion towards anything even remotely resembling compilation. Which is ironic, given that transpilation (aka converting from non-existent and future syntaxes to existing one) is Javascript's bread and butter. > The optimizations might not be ahead of time, but the net is > there's still a lot of room for reusing the same "compiled"/parsed work. As opposed to what? To compilers/transpilers that can, and do, the same thing? And can do significantly more things like run whole-program optimisations. Or, like Solid, can just remove the need for components in the resulting code. The world already agreed about 40-50 years ago that programming with strings is a bad idea. And now JS purists are willing to die on this hill (while inventing bizarre justifications and increasingly bizarre DSLs for anything remotely complex, see lit-html). And of course there's nothing wrong, or "worse" with DSL, or compilation. As evidenced by compiled frameworks being blazingly fast: https://krausest.github.io/js-framework-benchmark/2023/table_chrome_110.0.5481.77.html https://krausest.github.io/js-framework-benchmark/2023/table... and

by dmix 4y ago

mythz 4y ago

What you can do in a Vue SFC you can also do in a templated string component, if the component gets too big you can always break it down into smaller components as normal. Sure you can benefit from a smart IDE which understands templated strings, just as they improve the authoring UX for Vue SFC's. The Vue component used for its working CRUD Example is at [1] which is the verbose version, a more capable example [2] with a lot more functionality is available at [2] which uses the new AutoQueryGrid component to reduce the functionality down to 1 line. The point of adopting a traditional Multi Page App approach is that you don't need to build a large serious JS SPA frontend as the separate pages provides natural isolation where you only need to build isolated components for the functionality each page needs which is typically glue code that makes use of external libraries & components. [1] https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/wwwroot/Pages/Bookings.mjs https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/... [2] https://vue-mjs.web-templates.io/bookings-auto https://vue-mjs.web-templates.io/bookings-auto [3] https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/Pages/BookingsAuto.cshtml https://github.com/NetCoreTemplates/vue-mjs/blob/main/MyApp/...

rektide 4y ago

This seems like a case of caring way too much about something that's hardly very different. JSX versus tagged template strings can be incredibly similar to one another. The examples in this article are using vanilla template strings to author raw html, but that only misses a couple of nicities JSX has. There are tagged template string libraries like htm[1] that do include some of the few nicities JSX has, but which are actually compatible with the official language. [1] https://github.com/developit/htm https://github.com/developit/htm

dmitriid 4y ago
Define "compatible with the language". Anything you shove into a string and then parse yourself is "compatible with the language". Doesn't make it better or significantly different from systems that do this step earlier.
- rektide 4y ago
  Compatible with the language seems like a dead obvious concept to me: something you can do with the current TC39 EcmaScript language. Anything you do with JSX isnt compatible with the language. So that makes it worse & significantly different. Diving way into technics, tagged template strings, if called from a function, will have reference equality for the literals array. The optimizations might not be ahead of time, but the net is, even if the tagged template string is inline and single-phase (as opposed to moving your tagged template strings to the top level & having them "compile" & return a function to accept variables/children), there's still a lot of room for reusing the same "compiled"/parsed work.
  - dmitriid 4y ago
    > Compatible with the language seems like a dead obvious concept to me: something you can do with the current TC39 EcmaScript language. Most JS frameworks are written in JS. You can run React, Svelte, Vue etc. directly from the browser without a build step. > Anything you do with JSX isnt compatible with the language. So that makes it worse & significantly different. So, this is an artificial and absolutely arbitrary line that only looks good because you chose it to be so. Also, JS world is probably unique among all programming languages with such aversion towards anything even remotely resembling compilation. Which is ironic, given that transpilation (aka converting from non-existent and future syntaxes to existing one) is Javascript's bread and butter. > The optimizations might not be ahead of time, but the net is > there's still a lot of room for reusing the same "compiled"/parsed work. As opposed to what? To compilers/transpilers that can, and do, the same thing? And can do significantly more things like run whole-program optimisations. Or, like Solid, can just remove the need for components in the resulting code. The world already agreed about 40-50 years ago that programming with strings is a bad idea. And now JS purists are willing to die on this hill (while inventing bizarre justifications and increasingly bizarre DSLs for anything remotely complex, see lit-html). And of course there's nothing wrong, or "worse" with DSL, or compilation. As evidenced by compiled frameworks being blazingly fast: https://krausest.github.io/js-framework-benchmark/2023/table_chrome_110.0.5481.77.html https://krausest.github.io/js-framework-benchmark/2023/table... and