6 ms·

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

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)

jmisavage 6y ago
A lot of these apply to other frameworks too especially Angular, which has a very unhealthy love affair with decorators.
- searchableguy 6y ago
  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 6y ago
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 6y ago
  > 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.
  - sudders 6y ago
    This is amazing
  - erikrothoff 6y ago
    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 6y ago
      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.
airstrike 6y ago
Honest question, what's so bad about `this`?
- jeffkeen 6y ago
  OP doesn't like coding in javascript to feel like coding in javascript, I guess.
- lhorie 6y ago
  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)#Lexical_scope_vs._dynamic_scope https://en.wikipedia.org/wiki/Scope_(computer_science)#Lexic...
searchableguy 6y ago
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 6y ago
  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 https://github.com/machty/ember-concurrency
  - mnutt 6y ago
    ember-concurrency is probably at the top of the list for things I miss most when writing javascript outside of ember.

jmisavage 6y ago

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

searchableguy 6y ago
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 6y ago

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 6y ago
> 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.
- sudders 6y ago
  This is amazing
- erikrothoff 6y ago
  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 6y ago
    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.

airstrike 6y ago

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

jeffkeen 6y ago
OP doesn't like coding in javascript to feel like coding in javascript, I guess.
lhorie 6y ago
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)#Lexical_scope_vs._dynamic_scope https://en.wikipedia.org/wiki/Scope_(computer_science)#Lexic...

searchableguy 6y ago

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 6y ago
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 https://github.com/machty/ember-concurrency
- mnutt 6y ago
  ember-concurrency is probably at the top of the list for things I miss most when writing javascript outside of ember.