> I was hoping for less (or non-at-all) "stringly typing".

It's the curse of the template. Once you have them you inevitably start encoding more of your logic in magic-voodoo template directives.

The devtools (Jetbrains Webstorm for instance) automatically detect that `increment` refers to the method. So it actually works quite well in practice. And you can use @click="increment(any, args, here)" if you want. The syntax @click="increment" is just syntactic sugar for @click="increment($event)", I think.

It's cool if tooling helps with this. Thats important.

I'm mixed on vue because of the string bindings. I really like to know where my variables are coming from and really hate when two dependent uses but not actually the same thing...

That said, I'm happy to re-evaluate my stance... so what does it mean to be "the same thing"? I suppose in the past, I would say that the compiler thinks the things are the same, and it would be easy to change either:

1. If it is a value, I can set/change it in a single spot

2. If it's a token, it is easy to detect and change everywhere, and tooling will help my avoid misses.

That said, in React, if you were to mess up a 'token', the runtime would be very upset and it would be hard to have something like `onClick={incremant}` (note the a). Tools would make it super easy to spot.

What does vue do if you miss-type your bindings?

> That said, in React, if you were to mess up a 'token', the runtime would be very upset

The same is of course true for Vue. At runtime, it will spit an error if it doesn't know that token (variable, function, whatever it is).

My feeling is what you don't like are really the quotation marks because it looks weird. I had a similar feeling when I started with vue. However, it is really a matter of taste if you prefer the Vue @click="foo" or onClick={foo} syntax.

So, when the jsx is compiled for react onClick={foo} is really just part of an object: `{ onClick: foo }` which is actually using the token.

Believe me, I agree to an extend its a matter of taste, but I too like that my underlying understanding of whats happening under the hood can be followed by a raw debugger without following string based mappings.

In react I can set a debugger endpoint right before the return of render and see what all my local variables are... is anything like this possible in vue?

I agree with you on the preference part. I share the same preference as the GP. I've played a bit with Vue in the past, at the same time I was testing React. I've enjoyed Vue but the strings and template were a grim reminder of the Angular not-so-fun-times and passing members around per-reference and not "per string" made more sense in the general JavaScript way of programming, and so I ended up sticking with React.

Even with tooling support, those strings still make me wanting to look away...

throw an error saying "incremt is referenced during render..."

I personally think this is a non-argument to begin with, but the new API coupled with the fact that Vue supports the render function and JSX would give you what you want.

Still makes it harder to refactor, use code analysis/indexing tools and so on.

Since the way you build a vuejs application encourages breaking your code into small, mostly self contained, focused components this is rarely a real problem in my experience.

Tooling also seems to deal with it just fine.

I think what he means is why not use ++ in the click handler. We don't need a function to increment something.

Standard HTML, onclick="var++"

No, I think he's referring to the fact that the function increment is called by interpreting the string "increment".

you can do exactly that, they just wanted to showcase the methods option. often you would switch true to false doing:

`@click="isSomething = !isSomething"`

Exactly this. Template directives support a lot of JS functionality (while not encouraging it, like JSX does). That said, except in rare, extremely simple cases I still prefer wrapping that logic in a computed property or method, as it will inevitably grow more complex later.

You can use render functions instead of templates if you really want that.

It doesn't bother me though. Tooling (ESLint or TypeScript) will catch typos, missing methods, etc for you.

TSX is supported by Vue and, unlike templates, that is not opaque to the compiler. I recently switched the code in a side project of mine to TSX and it was worth the change.

Do you have any pointers on setting up TypeScript properly for the jsx render function while preserving intellisense? "Supported" is a bit tenuous based on the manual setup and shim creation required to get it all working nicely..

This is my setup:

- vue, @vue/composition-api

- Rollup

- Babel: @babel/preset-typescript, @babel/preset-env, @vue/babel-preset-app, babel-preset-vca-jsx

- Just pass `extensions: ['.js', '.jsx', '.ts', '.tsx']` to the Rollup babel plugin.

Make sure you are using createComponent inside a TSX file, and you'll get every feature that TS has to offer (as it is all native TS). Intellisense and static types are the only reason I dropped SFCs.

I'm not sure how this would work with Webpack, I've been enjoying Rollup more as things have just worked with no thought involved so far. I'm sure it can be done, though.

What's your Vue+Rollup configuration?

But that feels a bit like saying you can use React without JSX. Sure, you can, but it appears that the templates are a major selling point for Vue to many people. That's the part that's most baffling. (Well, not really baffling, as it's a pretty subjective matter. But not for me, at least :)

In vue you can do <button @click="increment()"> and it treats it the same. I tend to put the (), especially since I am almost always passing in some sort of object inside a loop.

Isn’t that still a string?

Would you be happier with the following?

<button @click=increment>

That is legal (or at least it is supposed to be, I've not tested it), but is not really different. This part of Vue parsing is dictated by the whatwg html specification, and the html spec says that <html lang=en> and <html lang="en"> are the same thing.