rxcfc

Scheduled maintenance shouldn't have to mean that _everything_ goes down at once.

Interestingly, I was just talking to someone yesterday about how Yehuda is very good at handing off projects. When he doesn't personally finish something he started, it's because he's handed off the work to someone else who is taking it to completion. I've never seen him abandon any project.

Not yet. It just happened and will need to be post-processed. I'm pretty sure all EmberConf talks will eventually end up online.

Emblem compiles to Handlebars so it will gain all of the benefits of Glimmer. FastBoot is only concerned with the initial render which is done on the server. Glimmer is concerned with updates so it will not directly affect FastBoot but will work with it.

Performance is a relative term. One could just as well argue that if you're really concerned with performance you should just write machine code.

It's pretty cool to see that Ember is still in the same ballpark, especially when you realize that Ember does a ton of stuff that Backbone doesn't do for you :)

Agreed. And I suspect Ember can get closer than that, if not even outdo React in some cases.

To be clear, while we're using Handlebars syntax, the underlying runtime is not the standard handlebars.js, but a custom version for Ember.

I should have added the caveat that there will always be a handful of cases where you do need absolute top performance. However, I do think that for the vast majority of apps we'll end up at a point where performance isn't the deciding factor. It doesn't mean that we shouldn't keep improving performance, just that being the fastest doesn't matter so much if all the options are very fast.

In regards to taking up an entire core, it's updating as fast as it possibly can, it's basically a stress test. In practice, updating this quickly isn't useful, you would want to throttle it for production use.

It's reasonably quick on an iPhone 6 (though obviously slower than on a desktop). In actual use you'd obviously design things a bit differently. Again, this is a performance test, not a real application.

Some information can be seen at the PR for Glimmer: https://github.com/emberjs/ember.js/pull/10501.

It's also worth noting that we're getting to the point where fastest doesn't really matter. Both Ember and React will be fast enough. Performance shouldn't be a deciding factor.

This is only meaningful if Dust has all the other features that Ember templating has.

Ember still uses the Handlebars syntax, but we don't use the standard Handlebars runtime anymore.

You shouldn't be both manually manipulating the DOM _and_ using Handlebars mustaches for the same element. Since there wouldn't be mustaches, Glimmer would ignore these cases. In general, you should only be using jQuery plugins for special cases not covered by Ember anyway.

In the first case, he was using an `ObjectController` without understanding the special behavior of the `model`/`content` property.

In the second case, he used HTML comments to comment out Handlebars code, not realizing that he should have used Handlebars comments.

Sorry to hear that you've been having trouble with Ember. Let me see if I can answer a few questions.

1) Layouts vs. Views vs. Components

A good place to start on this is the guides: http://emberjs.com/guides/views/adding-layouts-to-views/ http://emberjs.com/guides/views/ http://emberjs.com/guides/components/

From reading those, it should be pretty clear how layouts differ. I admit that it may be a bit less clear how views and components differ. Components are actually a more isolated type of view. Views have been around for longer, but in the future, we're going to discourage people creating custom view classes in favor of using components primarily. If you're not sure whether to use a view or a component, go with a component first.

2) Ember Data

Ember Data isn't a part of Ember Core, and for a good reason. While Ember Data is certainly a useable product (myself and many other do use it in production), it's not yet as mature as Ember Core (hence still being in beta). If Ember Data isn't good for you yet, you don't need to use it. Discourse is an example of a large Ember app that completely forgoes Ember Data.

3) Templates and Views

The template is rendered inside of the view's element which explains this. Alternatively, specify `tagName` as a property when using `{{view}}` or a component helper.

4) Documentation

The guides have a ton of information so you should definitely look there first. Also, if your company is really investing in Ember there are some good paid trainings available, including online courses. Tilde, my employer, has an online training (http://www.tilde.io/events/introduction-to-ember-online/) as does CodeSchool (who I do not work for) (https://www.codeschool.com/courses/warming-up-with-emberjs), among others. Since Ember has reached 1.0 a number of months ago, the API has stabilized and documentation will be valid for much longer.

I'm confused. Are you proposing that web apps don't use URLs? If so, this seems pretty antithetical to the very nature of the web. One of the things that often aggravates people about web apps is that the back (and refresh) button is often broken because of a disregard for URLs. You can see Tom Dale give a defense of URLs here http://2013.jsconf.eu/speakers/tom-dale-stop-breaking-the-we....

As far as Ember Data goes, this is something that it's clear that a lot of people do indeed want. That said, you can use Ember perfectly well without Ember Data (see Discourse for example).

It's funny that you point to Rails as an example of consensus, because when you look at the server-side development community as a whole, there is certainly not consensus that the Rails way is correct. I wouldn't expect complete consensus on the client side any more than I would expect complete consensus on the server side. Rails (and others) have shown that you can have multiple healthy ecosystems each with their own points of consensus.

I understand the frustration of the author, but it's hard to tell exactly what the source of his issues is. Not enough information is provided in his descriptions to actually understand what is going on. I suspect that either he has run into a bug (which of course should be fixed) or that he's misunderstanding the behavior. It's very possible that he was given some bad explanations for the behavior which has further confused him. I've reached out to him to see if I can get some more insight into the details of the issues.

Whoops, I misread.

You weren't coming to HN to find real discourse were you? :)

Thanks for pointing this out, the comments are set up through Disqus so the problem may be on their end. We'll look into it.

Did you read the whole forum thread? We are planning to address his complaints.

Agreed, more screencasts would be wonderful. Unfortunately, we haven't had time for this yet. It's something we'd love to do if/when time permits.

There are a few Ember screencasts: https://peepcode.com/products/emberjs http://railscasts.com/episodes/408-ember-part-1 http://railscasts.com/episodes/410-ember-part-2

Unfortunately, both cost money at the moment but I've heard they're worth it.

It didn't come earlier because some of the core patterns were still solidifying. It would have been premature to put together something that was likely to change a lot. Now that we've hit RC the API is stable so it makes much more sense.

I think it just shows that HN likes controversy. Which is news to no one :)

Knowing Trek, I think his frustration here is in large part with himself. He cares very deeply about giving users a good experience with Ember and knows that we aren't achieving that as well as we'd like. We've been planning and working on an improved Getting Started story for a while now but, because all of us on the Core Team are very busy with our day jobs, it's been slower going that we would have liked.

To have more people point out your shortcomings when you're already well aware of them is very frustrating. I think this is what we're seeing in Trek's response. Now that doesn't mean that I think his response is helpful - it's not. But I do want it to be clear that we do care about these issues and sometimes maybe too much.

When our new Getting Started Guide is finally released, I promise that we will do our best to address all of the different comments and complaints we receive from our users.

-Peter Wagenet, Ember Core Team Member

You're right, this should have specifically been in response to the post that was expressing frustration with Trek.