Javascript Template Library

💡 Ideas
1

I think that many experienced javascript developers are tired of replicating functions available in lodash, moment and other libraries simply to avoid bloat and maintenance headaches.

To that end, there should be an ECMA standard set of Math, Date, String, and other functions that are sometimes used but not really important enough to be included as the main ECMA standard for the language.

Things like composing, mapping objects to arrays and other structures, sleep, css manipulation, and many other sometimes useful items. Think STL in c++ only using the most popular NPM repo items as the core source code.

By now most of you will agree that adding repo's to one's code creates a new form of PTSD (Post Repo Addition Trama Syndrome ?)

Also, franken-repos (oops I mean mono-repos) would really benefit from such a natural extension to the ECMA standard

1 Like
2

So, what exactly are you proposing here? A set of standard functions that a platform can optionally choose to implement if it wants? That would only help developers who only target the specific platforms that implement it. Specific platforms already do add a ton of their own extra functions that aren't in the JavaScript spec. (The standard browser libraries are one such example - things like getElementById() aren't part of Javascript's spec, but are from another spec that all browsers follow. Node adds a lot of their own stuff too).

This built-in module proposal could be related to what you're looking for.

1 Like
3

Cheers, I think that is what i was thinking of... but i could not find it on the system when I looked for it.

I think what the real issue is that npm modules are in general very hard to justify in a production environment and I find myself rewriting much of the 3rd party code so that i can reduce code bloat, security risk and increase download performance.

The is the inevitable outcome of npm's success at doing its job correctly.

4

How are they hard to justify in a production environment?

5

next phrase:
"reduce code bloat, security risk and increase download performance"

The one that is the biggest for me however is the number of indirect and therefore unknown dependencies that create uncontrollable risk in someone else's code.

The worst types of bugs are bugs when a dependency in a dependency in a dependency is deprecated and or replaced with the next release that is subtly incompatible with the previous.

1 Like
6

@theScottyJam I have a similar question to this topic, would it be possible to request that Javascript have native template support?

  1. I like to write code, and most of the time I avoid using libraries and modules. I do not want to infringe any rights or intellectual property in specific cases. In some cases if the library is GPL licensed, I avoid it and use the MIT license which is less restrictive. But thus, so ... there are libraries that use the GPL license and not MIT. Some projects I create are commercial and source code is private. That's why I prefer js libraries with MIT and not GPL.
  2. Some projects that created in nodejs had libraries: React.js, Vue.js, Angular.js, Lodash, Underscore.js, Backbone.js, Ember.js, Mustache.js, Handlerbars.js, Typescript/Coffescript/Flow, Pug.js - Most of these libraries make Javascript interesting(I really like this things). Natively, JS as far as I'm aware didn't have things like Typescript or React.js can have.
  3. One thing I miss would be the template available in React.js. I wanted to write something like this JS without React.js :
example 1
const element = <h1>Hello, world!</h1>;
example 2
function getGreeting(user) {
  if (user) {
    return <h1>Hello, {formatName(user)}!</h1>;  }
  return <h1>Hello, Stranger.</h1>;}
example 4
const element = <img src={user.avatarUrl}></img>;
example 5
const element = (
  <div>
    <h1>Hello!</h1>
    <h2>Good to see you here.</h2>
  </div>
);
example 6
const element = (
  <h1 className="greeting">
    Hello, world!
  </h1>
);

or like Vue.js:

example 1

<!--
Say Hello World with Vue!
-->

<script>
export default {
  data() {
    return {
      message: 'Hello World!'
    }
  }
}
</script>

<template>
  <h1>{{ message }}</h1>
</template>

or like Handlebars 

const values = {
  firstname: "Yehuda",
  lastname: "Katz",
}

const view = <p>{values.firstname, values.lastname}</p>
console.log(view);

My idea is create an ATE: "Agnostic Template Engine in JavaScript":

  • Based on React.js, Vue.js, Handlebars.js
  • A = Agnostic, T = Template, E = Engine or ATE.js

reference

7

We already have the syntax to do this. It's called template literal strings. React came out before template literal strings were a thing - I'm betting if React came a little later, they would have just used them instead of making a new super-set language. (Perhaps they would still provide compile-time tooling to transform the template literals into something else, but such toolilng could be optional). I wish they provided the option to use them today, as it could make build-tooling a little easier to deal with when you're just getting started.

So, here are a couple of your examples, rewritten with template literals.

const element = jsx`<h1>Hello, world!</h1>`;

function getGreeting(user) {
  if (user) {
    return jsx`<h1>Hello, ${formatName(user)}!</h1>`; 
  return jsx`<h1>Hello, Stranger.</h1>`;}
}

const element = jsx`<img src=${user.avatarUrl}></img>`;

It looks like both Vue and Handlebars came out before es6 as well, so they were pretty limited in what they could use as well. Vue certainly could have chosen to use template tags as well had they come out a little later, but perhaps they wouldn't have chosen to use them, even if they could. Handlebars is a bit of a different story in that it's just a templating engine. I believe their philosophy follows the idea of separating the view from the logic behind it, so they probably wouldn't want to use any sort of feature that would mix the two together in the same file.

JavaScript itself doesn't provide any sort of built-in way to parse these templates, nor should it. These templates are very specific to HTML, and JavaScript doesn't always run in an enviornment where HTML can be used. However, providing a new, built-in html template tag that could be used to generate HTML and interpolate variables in a safe way could be useful, and perhaps a discussion could be started on the WICG forms - they're the ones in charge of providing the standard web APIs that all browsers must implement.

1 Like
8

"However, providing a new, built-in html template tag that could be used to generate HTML and interpolate variables in a safe way could be useful".

  • So... What you said is very interesting. That's great, thank you so much for the feedback ^^ You're amazing... I'm talking about this because I thought the same. Recently, I saw a repository that follows this idea... I'll leave the link here: HTML-as-programming-language, html-lang

example

<!-- Set name -->
<val name="World"></val>

<!-- Compute Message -->
<val message:?="'Hello ' + name"></val>

Note:

The html itself would have these features in HTMLang

"and perhaps a discussion could be started on the WICG forms - they're the ones in charge of providing the standard web APIs that all browsers must implement."

  • Thanks for this information, this is very interesting.
1 Like
9

It's already been done: lit-html.

1 Like
10

I'm sure there's many templating libraries out there that use template strings and produce html, there's just not anything built in to browsers that do it. Having a built-in API sounds like it was one of @willow_grace's desires, as it can be a hassle to deal with third party tooling, especially for something as common as building custom html.

1 Like