That link details other reasons, such as tooling. On Wed, Jan 13, 2016, 18:11 Isiah Meadows <[email protected]> wrote:
> Problem is: your idea has already been tried and found to be pretty slow. > React devs did briefly consider this, but found that it had fundamental > speed limitations. And precompilation is already happening with existing > templates, even though building them normally is still cheap to do. > > http://facebook.github.io/jsx/#why-not-template-literals > > On Wed, Jan 13, 2016, 05:45 /#!/JoePea <[email protected]> wrote: > >> > modulo the obvious mistake >> >> Oops. x] >> >> > you could use it as a vdom library as almost like a Lisp reader macro: >> >> That would be interesting. There's still lots of runtime processing >> though. Maybe a build-time tool can also optimize it though, but if it >> happens to be executed at runtime it'll just work. Here's a JSX-like >> concept, let's call it 'xjs' for sake of argument: >> >> ``` >> let style = {background: 'turquoise'} >> let content = xjs`<p>hello</p>` >> let el = xjs` >> <div style=${styleObject}> >> ${content} >> </div> >> ` >> ``` >> >> It could be compiled statically as well as have a runtime template-tag >> implementation. >> >> On Wed, Jan 13, 2016 at 12:05 AM, Isiah Meadows <[email protected]> >> wrote: >> > A use I thought up (although I got lazy and abandoned it later) was an >> > `exec` template tag, for executing commands. Or, and this just came off >> the >> > to of my head, you could use it as a vdom library as almost like a Lisp >> > reader macro: >> > >> > ```js >> > n`.form-ctrl`( >> > n`input#input`("input"), >> > n`a[href="/submit.html"]`("Submit")) >> > ``` >> > >> > >> > On Tue, Jan 12, 2016, 17:34 Alexander Jones <[email protected]> wrote: >> >> >> >> The two code samples you posted are equivalent (modulo the obvious >> >> mistake). AFAIU there is still only a single parsing pass for template >> >> strings. >> >> >> >> On Tuesday, 12 January 2016, /#!/JoePea <[email protected]> wrote: >> >>> >> >>> The thing with template strings is that they are used at runtime. This >> >>> could be slow if we're compiling things at runtime all the time, >> >>> whereas a server-side templating solution might lead JavaScript >> >>> functions compiled from templates (like in the case with Meteor Blaze >> >>> Spacebars or React JSX), which can be faster at runtime. >> >>> >> >>> What are template strings good for besides the obvious benefit that >> >>> they make things like >> >>> >> >>> ``` >> >>> var str = "llo" >> >>> console.log(`he${str} world!`) >> >>> ``` >> >>> >> >>> easier to read than >> >>> >> >>> ``` >> >>> var str = "llo" >> >>> console.log('he'+'str'+' world!') >> >>> ``` >> >>> >> >>> ? >> >>> >> >>> Maybe writing regexes can be nicer with template strings? I gave it a >> >>> try at npmjs.com/regexr. >> >>> >> >>> On Mon, Jan 11, 2016 at 8:43 AM, Manuel Di Iorio <[email protected]> >> >>> wrote: >> >>> > Yes Bob, after a personal testing with a complete template engine >> using >> >>> > the >> >>> > ES6 template strings, I realized that their use (in mine use case, >> of >> >>> > course) is slowest than the approach that I'm using right now (like >> the >> >>> > Underscore template). Thanks everyone :) >> >>> > >> >>> > _______________________________________________ >> >>> > es-discuss mailing list >> >>> > [email protected] >> >>> > https://mail.mozilla.org/listinfo/es-discuss >> >>> > >> >>> _______________________________________________ >> >>> es-discuss mailing list >> >>> [email protected] >> >>> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> _______________________________________________ >> >> es-discuss mailing list >> >> [email protected] >> >> https://mail.mozilla.org/listinfo/es-discuss >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
