# Defining dynamic comments on the fly **URL:** \ **Category:** 💡 Ideas\ **Tags:** proposal\ **Created:** [September 29, 2021, 11:49am UTC](https://es.discourse.group/t/defining-dynamic-comments-on-the-fly/1003 "2021-09-29T11:49:24Z")\ **Posts on this page:** 1\ **Showing post:** 25
**Author:** ![GHNewbiee](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/ghnewbiee/32/1042_2.png) [@GHNewbiee](https://es.discourse.group/u/GHNewbiee)\ **Post date:** [October 1, 2021, 9:15am UTC](https://es.discourse.group/t/defining-dynamic-comments-on-the-fly/1003/25 "2021-10-01T09:15:56Z")
> The ability to add comments to a template literal should be seen as an extra nice-to-have feature, not a "JavaScript is broken and must be fixed" thing. We see the same thing from different aspect. Imagine: - a bus without grips/handles, - a train, airplane without toilets, and - a long highway without rest/parking areas All of them fulfills their purpose of construction in an excellent constructive way, ie to help people move from one place to another. Now, imagine that one needs to evacuate his/herself. One, after being finally evacuated on his/herself, starts complaining and blaming the maker. One of the maker's company contends that the construction is quite consistent and predictable with its purpose. The ability to add toilets to the construction should be seen as an extra nice-to-have feature, not a "Construction defect/lack and must be fixed" thing. Very nice! > So, for example, we could make ${\* be a comment-start, and \*} be a comment end. It is obvious, that any solution has to work as per code chunk and not as per expression to help de-activating/isolating many expressions at the same time. It should also be combined with HTML comments without problem. > Or, if we accept that JavaScript is not broken in its current state (along with every other language with multi-line strings), then we could also discuss adding smarts to editors, so that they can do the ${''/\* ... \*/} workaround. Editor's smarts is not a solution; it's just a "throw the ball to someone else" workaround, like maker's asking subcontractor to install bigger windows and advising you to take your b@ttocks out of them and evacuate yourself! Please transfer your comments to > [@Global interpretation of comments within tagged template literals](https://es.discourse.group/t/global-interpretation-of-comments-within-tagged-template-literals/1005): > > Description Tagged template literals are commonly used by web components libraries. They can also include CSS code, HTML code and embedded expressions (a.k.a. substitutions). ES provides its own: semantics (//... and /\* ... \*/) for instructing parser to ignore strings referred as comment, and tagged template literals The problem ES parser fails to recognize and, hence, parse correctly (ie to ignore) its own comments within its own tagged template literals. Example I wish to de-activate a… since there is nothing related to dynamic comments definition. --- _[View the full topic](https://es.discourse.group/t/defining-dynamic-comments-on-the-fly/1003)._