Why syntax for calling helper with parameters has to be so different from calling function in JavaScript?
Why not making it the same to achieve consistency and simplicity.
Writing {{sayHello("David","20")}} immediately looks like calling a function which is exactly what we are doing.
In contrast {{sayHello "David" "20"}} might mean whatever if you don’t know the syntax.
Also now we have to learn two different syntaxes for doing the same thing which increases learning time and might be confusing if wrong syntax is used in the wrong place.
Or maybe there is a reason for different syntax?
App.html
<body>
<b>{{sayHello "David" "20"}}</b>
</body>
App.js
if (Meteor.isClient) {
Template.body.helpers({
sayHello: function (name, age) {
return name + " is " + age + " years old.";
}
});
}
Thanks for answering.
But people are here talking about using parentheses to allow for sub-expressions and not about using them to make helper calls more like JavaScript function calls.
But it was a useful read.
the traditional invocation syntax is used when you actually invoke the function
this is not the case of spacebars - the invocation is not made immediately per the user’s syntax, as Spacebars has to first parse the code and then invoke on behalf of the programmer
keeping the arguments separate would save parsing steps, for the cost of a syntax difference, which I believe to be a non-issue
I think that programmers should be protected from the plumbing.
Programmers should only focus on what they want to achieve and not on helping engine/framework out because it is incapable of doing things automatically.
Things are already to complicated even without that.
I don’t think this kind of reasoning is in line with Meteor goal of being super simple.
If there is technically no other way to do it then fine.
But to sacrifice simplicity to help out the machine - not cool.
Why should “keeping the arguments separate save parsing steps”.
When you use round brackets and commas they are still separated?
Here “cost of a syntax difference” is having to learn two sets of rules to do exactly the same thing - call a function with parameters. That is a big deal because things are super complicated even without this. At least this is my point of view.
I understand this is not a big deal if you are smart and have good memory. Most IT solutions are made by smart people for smart people which is why everybody else is struggling to use them. I really dislike that. I think even more focus should be given to simplicity. I think programming is unnecessary to complicated.
I prefer not having the parentheses. Most of the time you’ll have only a helper function and its parameters enclosed in {{ }} and not super long expressions or nested closures thus the parens are just visual clutter in the code. Consistency for the sake of consistency is not necessary, in my opinion.
Personally I prefer languages that don’t require the parens for functions (like Ruby or CoffeeScript, for example) as it makes it more prose-like and readable.
for example if you had a helper count that returned the length of a parameter:
while reading your reply, my first impression was something along, “come on man, it’s just a minor difference”
but I’ve changed my mind; I think there’s a lot to what you say - cultivating good, experienced developers is very hard, and I believe Meteor in particular has set out to be more accessible to the broader community of web professionals (i.e. designers)
some people are less skilled at memorizing technical details, although they may be gifted, logical thinkers
with that said, consistency and simplification may be more important than I’d thought
For instance I am always having a lot of problems when using JavaScript - PHP combo.
They have similar syntax but if you use JavaScript syntax while writing PHP code then things might not work.
So very often I have found myself in situation when app wouldn’t work and I would just stare at the code thinking “WTF, This is a perfectly good syntax. Arghhh”
I call this a black hole where you just can’t see what is wrong no matter how long you stare at it and no matter how obvious it is. And the more similar the syntax is the more difficult is to detect it.
Also I am not good with details. I like to think in logical terms. And then when I have to actually write some code I always have to go copy paste because I can never remember the EXACT syntax to do what I want to do.
I think the simple reason is that handlebars does it this way, and meteor’s templating language is based on handlebars. We’ve been exploring making things more like JavaScript, I think I agree with you mostly, but it would be a big change with maybe not enough benefit to justify it right now. I hope that in the future you can just type JavaScript expressions inside your templates instead of making helpers for everything.
Well this is EXACTY what I was afraid the real reason is. Simply being based on something else that does things in that way and not being to concerned for consistency and simplicity because it doesn’t look like it is to important. And it is not if you are smart and have good memory like I already mentioned. And now we don’t want to break backward compatibility.
Yeah, it would be create if we could use JavaScript even there, that would be really along the lines of Meteor framework. But thank you for the honest answer. I feel a little bit better now that I know the answer.
Actually I don’t have problems with helpers. I think that logic should be in controller. I was just thinking that it would be nice for Spacebars syntax to be more like JavaScript syntax. That’s all.
I think it was a great decision to use an existing popular templating language so that people could have something familiar when starting to learn Meteor - I think at the time Handlebars was very popular and used often with Backbone. Even now, frameworks like Ember and Ractive use something very similar to handlebars, and angular has something totally different. It is nice that React lets you use normal JS, but it’s relatively new.
I do agree though that compared to templating languages from Rails and Django, handlebars isn’t great and is unnecessarily different from JavaScript syntax.
No matter how many people knew handlebar at that time I am sure more people new JavaScript and those that new handlebar probably new JavaScript also.
So I feel that templating engine that looks like JavaScript would be much easier to learn by more people since it includes both those that know JavaScript and those that know handlebar.
Also it seams quite arbitrary to use JavaScript to replace Server and DB languages and then stop and not use it to replace templating language.
I presume that decision to adapt handlebar was easier and faster option rather then trying to reinvent the wheel with JavaScript on Templating side also.
