<amp-bind> has proved to be a highly flexible and useful mechanism to allow all sorts of interactions in AMP sites! I imagine it’s now being used for all sorts of cases that weren’t anticipated. So here are some reasons I think it would be really impactful to allow developers to reference real JavaScript functions or methods in their expressions… not just JavaScript expressions encased in strings.
Now that we have JavaScript in Workers, this seems possible to me - especially as I'm told that <amp-bind> spins up a Worker for safe JS execution anyway. Could we use the same magic that makes <amp-script> possible?
const apiBaseURL = 'https://api.foo.com/wow';
function getUrl(filters) {
let queryString = '';
// here lives logic to check filters and construct query string . . .
return apiBaseURL + '?' + queryString;
}
Or, we could have developers place their JavaScript inside a class or object with a standard name. Etc.
Ok. But... why?
Nonsimple logic is hard to squash into a single expression. JavaScript often makes it possible, with nested lambda functions, .map()’s, and the like, but of course there’s a severe cost here in developer experience: such code is hard to read, hard to maintain, and of course hard to debug. I'm thinking, for example, of a case where someone wanted to format a number by inserting separators after every three digits. This is possible in a single expression, but really hard.
JavaScript in strings makes it hard to be a good programmer. <amp-bind-macro> does let you share code around a page, but of course it doesn’t let you use comments, helper functions, classes, or any of the techniques that make you feel good and that make your code maintainable. And of course your editor won’t show syntax highlighting or flag errors, so you can fall victim to all sorts of silly errors that you’d usually notice.
With JavaScript in strings, you can’t set breakpoints. With JavaScript in a Worker, you can.
With JavaScript in strings, you can’t set local variables. You can’t share data among your expressions.
Currently, it’s pretty easy to hit limits on operators and the like. This just frustrates developers.
Most importantly, on a few occasions, I’ve given talks on AMP, and afterwards I’ve met a developer who’s said something like, “I was looking for a framework for my next project, and I considered React and AMP, but I went with React because all those JS expressions in strings looked hacky to me.” In other words, I’m personally interested in allowing binding to reference real JS because it will make AMP seem far more developer-friendly. It will let developers feel more comfortable making the leap to AMP.
Finally, I do wonder if this would help people make a more smooth transition to <amp-script>. They’d be using it already for binding expressions! It would encourage fans of the traditional interactive components to try out the new one.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
<amp-bind>
has proved to be a highly flexible and useful mechanism to allow all sorts of interactions in AMP sites! I imagine it’s now being used for all sorts of cases that weren’t anticipated. So here are some reasons I think it would be really impactful to allow developers to reference real JavaScript functions or methods in theirNow that we have JavaScript in Workers, this seems possible to me - especially as I'm told that
<amp-bind>
spins up a Worker for safe JS execution anyway. Could we use the same magic that makes<amp-script>
possible?So, for example:
flights.html
script.js
Or, we could have developers place their JavaScript inside a class or object with a standard name. Etc.
Ok. But... why?
Nonsimple logic is hard to squash into a single expression. JavaScript often makes it possible, with nested lambda functions,
.map()
’s, and the like, but of course there’s a severe cost here in developer experience: such code is hard to read, hard to maintain, and of course hard to debug. I'm thinking, for example, of a case where someone wanted to format a number by inserting separators after every three digits. This is possible in a single expression, but really hard.JavaScript in strings makes it hard to be a good programmer.
<amp-bind-macro>
does let you share code around a page, but of course it doesn’t let you use comments, helper functions, classes, or any of the techniques that make you feel good and that make your code maintainable. And of course your editor won’t show syntax highlighting or flag errors, so you can fall victim to all sorts of silly errors that you’d usually notice.With JavaScript in strings, you can’t set breakpoints. With JavaScript in a Worker, you can.
With JavaScript in strings, you can’t set local variables. You can’t share data among your expressions.
Currently, it’s pretty easy to hit limits on operators and the like. This just frustrates developers.
Most importantly, on a few occasions, I’ve given talks on AMP, and afterwards I’ve met a developer who’s said something like, “I was looking for a framework for my next project, and I considered React and AMP, but I went with React because all those JS expressions in strings looked hacky to me.” In other words, I’m personally interested in allowing binding to reference real JS because it will make AMP seem far more developer-friendly. It will let developers feel more comfortable making the leap to AMP.
Finally, I do wonder if this would help people make a more smooth transition to
<amp-script>
. They’d be using it already for binding expressions! It would encourage fans of the traditional interactive components to try out the new one./cc @nainar , @choumx