[isakkeyten]

From a perspective of someone who codes react, what i dont like in ember:

- this this this, so many this keywords

- not a fan of decorators

- constructor and super

- mutability (unless it hides an immutable nature)

- hbs feels weirder to me than jsx

- the fact that you have yet another filetype in your code means even the tiniest components MUST be in more than 1 file, react lets you choose (edit: i rushed, seems there are template literals one can use)

[_630w]

Tbf, I would gladly take mutability or impureness over unnecessarily complicated approach. One example of it is the suspense api in react. Suspense uses a promise throw approach opposed to generators. Your code throws a promise and suspense catches it to render fallback until it is resolved.

You end up with few ugly situations. First, I hate that I have to wrap my components (what if you want different fallback for different components? You end up with many wraps), how my UI will render is not isolated anymore. I often end up returning loading view from the components as we as well using it as a fallback for suspense. It just feels wrong. I lack control.

[holler]

for things like loading state with ember we use a library called ember-concurrency that uses the generator approach. It's very nice!

Example you can create some "task" (promise-like), then in a template you have automatic access to it's state so e.g.

``` {{#if this.fetchStoriesTask.isRunning}} loading... {{else}} <span>Loaded 10 Stories</span> {{/if}} ``` https://github.com/machty/ember-concurrency

[jmisavage]

A lot of these apply to other frameworks too especially Angular, which has a very unhealthy love affair with decorators.

[searchableguy]

I am curious where decorators make sense. I find them unreadable with little to gain back so I avoid writing them myself. Class extensions works for most of the use cases of decorators. I guess they are helpful when you need to modify class methods and properties.

[erikrothoff]

I like and use Ember a lot, but the one gripe I have is that Handlebars uses s-expressions instead of just inline JS. The constant context switch is massive and it’s not possible to hook into Typescript types, and I doubt it ever will.

Would love the possibility to enable a flag to just enable JS-in HBS like

  {{#if this.model.isEnabled(this.byOtherVariable}}
    {{aHelperCall(this.args.thing)}}
  {{/if}}

Kinda like a hybrid of JSX and HBS, but combining the best of both worlds.

[chriskrycho]

> it’s not possible to hook into Typescript types, and I doubt it ever will

While it's not possible today, it's definitely possible in principle. (Vue is a great example of this!)

The folks working on TS integration in Ember (of whom I am one) are very well aware both of the problem, what it will take to solve it, and what the state of the art is elsewhere. No timelines, but we're working on it and when we're done the experience should be comparable to TSX. All of us working on it think TSX is a killer bit of DX and it absolutely is a thing we're aiming to match.

[airstrike]

Honest question, what's so bad about `this`?

[lhorie]

Dynamic scope[1] is generally considered to be harder to reason about since their values are not determined by where they appear in a file (but rather by how the code executes at runtime)

[1] https://en.wikipedia.org/wiki/Scope_(computer_science)#Lexic...

[jeffkeen]

OP doesn't like coding in javascript to feel like coding in javascript, I guess.