[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

[mnutt]

ember-concurrency is probably at the top of the list for things I miss most when writing javascript outside of ember.

[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.

[erikrothoff]

Really cool, didn't know Vue had this. It's great that it's in the works, and I'm really really looking forward to it. Will it be statically typed s-expression or more like regular JS? I spoke a bit to pzuraq about this on Reddit and it seems to be still s-expressions going forward?

[chriskrycho]

What we're aiming for at this point is 100% TS support for the current Glimmer syntax—we expressly want to support Ember and Glimmer usage as they are today. If Glimmer/Ember itself were to move toward supporting something more like the way Svelte's templates work (which is closer to what we could support while maintaining the tradeoffs Glimmer makes relative to JSX), we'd of course move to support that as well, but there's nothing like that planned at the moment.

[sudders]

This is amazing

[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.