Discussion on: The EmberJS of the future... today!

[NullVoxPopuli]

Decorators are never the saving grace of any language, and any framework that relies heavily on them is misusing the base language, or making up for the language.

Can you expand on this? or, why do you think this? I think it's a good way to add behavior. Java, however, is historically known for abusing annotations/decorators.

---

Have you seen this thread? reddit.com/r/javascript/comments/9... I see from your github that you use Vue, so, I don't know how much of the comparison of jsx vs ember-templates translates..

{{input is a bad fix for prop binding and event handling.

can you expand on this?

they could have used template string functions so that it worked in javascript too,

there is actually a reason for not using javascript for the templates: youtube.com/watch?v=nXCSloXZ-wc (it's a 30 minute video, so.. I guess only watch if you're really curious.

Do the spec approved thing and ensure you're including a - in your props if you're having conflicts and you'll never smoosh anything again.

but class, style, tabindex, checked, value, id, href, etc are all non-hyphenated native html attributes. So, the differentiation is nice, I think :)

DI is just a more opaque import system

you can't really manage class instances with just import.

I now have to debug the black box, rather than my own code.

Why use anything other than assembly then? every tool is an abstraction, and it is OK to abstract upon other abstractions. Documentation and understanding is key. :)

And Keyboard Accessibility hookup via XML just reminds me of dated desktop app layout systems and ColdFusion

I'm personally fairly new to this, so -- what would you do?

[Evan Verworn]

Decorators are never the saving grace of any language, and any framework that relies heavily on them is misusing the base language, or making up for the language.

Can you expand on this? or, why do you think this?

Javascript/Typescript are extremely dynamic and expressive languages. Why do you think you need them? What do they actually accomplish that's hasn't been implemented more cleanly by another framework without them? Admittedly Ember isn't as bad as Angular is with this.

Re: {{input

Why do you like this? How is this better than a directive that injects and listens to changes of the prop? Vue has v-model="variable" that can be put onto any component. How is a handlebar helper that is tied to a form input better? How is this not just considered bloat to you?

Re: {{t

Not having the templates be javascript is fine. The issue I was talking about is I can't use that {{t helper in a javascript method of mine. I'm sure Ember has an alternative for accessing the i18n strings in JS but that was a great opportunity that they missed out on.

Re: Smooshing

Sure

you can't really manage class instances with just import.

You really can. My prefered way if you want a singleton service export default new MyService(). Bam, shared instance, and there can only ever be one. Or attach it to your root App and $emit() or trigger() from any child component.

DI is a pattern, it's fine to use it, I have too, but there are better ways.

Re: Keyboard XML

On a second viewing it's not bad, I'm just not used to it. Polymer did a lot of this too, but I'd just listen to the keys. I don't know how the full ember event system works but in Vue <MyComponent @keydown.alt.115="modelVisible = !modelVisible" ... I like how expressive and customizable it is and there isn't anything new to learn, you just use the event system, like you always have.

[NullVoxPopuli]

Javascript/Typescript are extremely dynamic and expressive languages. Why do you think you need them?

How else would you denote something via shorthand as 'tracked' / cached so that it only updates when it needs to?

Why do you like this? How is this better than a directive that injects and listens to changes of the prop? Vue has v-model="variable" that can be put onto any component. How is a handlebar helper that is tied to a form input better? How is this not just considered bloat to you?

It's actually a shorthand, so, in Ember, you can totally just do:

<input value={{this.something}} oninput={{action this.updateSomething}} />

where then in your JS, you'd need:

updateSomething(e)  {
  const value = e.target.value;

  this.set('something', value);
  // note that set is going away in the future as ember moves away from it's pre-es6 object model (soon)
  // set is used as a bit of a trigger to update all the cached / dependent computed properties once before a re-render. 
  // once set is removed, this'll be wrapped behavior from the `@tracked` decorator
  // NOTE: for any React readers, this is like this.setState, but with super powers :)
}

So, that is equiv to:

{{input value=something onChange=(action (mut something))}}

so, no js involved. It's just a personal preference, imo. There are plenty of ember people who opt for as much of the native DOM behavior as possible.

side question: what all does v-model="variable do in Vue? it doesn't seem specific to anything and seems somewhat generic? Above, I use value= because an input expects a value.

Not having the templates be javascript is fine. The issue I was talking about is I can't use that {{t helper in a javascript method of mine. I'm sure Ember has an alternative for accessing the i18n strings in JS but that was a great opportunity that they missed out on.

Most helpers, like t, have two exports. 1. A default export (used by templates), and 2. A named export of a pure function that actually does the behavior. The named export is what can get imported into the js.
For t, specifically, it's exposed in additional ways as a service, so you can bind changes in your app to a change in locale but also as a direct import

You really can. My prefered way if you want a singleton service export default new MyService()

Personally, I think this is an accident of how bundlers evaluate scripts at build time.

DI is a pattern, it's fine to use it, I have too, but there are better ways.

to each their own. most things have purposes.

On a second viewing it's not bad, I'm just not used to it. Polymer did a lot of this too, but I'd just listen to the keys. I don't know how the full ember event system works but in Vue

So, my keyboard usage here is an API that I came up with (linked, is the template-less component that is in the screenshot) using lower-level keyboard event handling. I also didn't want my key events tied to a specific component (though, that is certainly an option, the lib I'm using is very flexible ).

I personally am not a fan of dynamically interpreted keys (even though there isn't a real good way around it when it comes to defining the shortcuts)), but I'd write your example (with my existing KeyboardPress component)

<KeyboardPress @key="alt+s" @onKeyDown={{action this.toggleModelVisibility}} />

I'd imagine though, if you wanted similar behavior from Vue, you could get close. You'd likely have to eval that string "modelVisible = !modelVisible", so.. that could be risky.