Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
rxcfc
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
8 ms
·
1.
▲
by
rxcfc
8y ago
Scheduled maintenance shouldn't have to mean that _everything_ goes down at once.
2.
▲
by
rxcfc
12y ago
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 i
3.
▲
by
rxcfc
12y ago
Not yet. It just happened and will need to be post-processed. I'm pretty sure all EmberConf talks will eventually end up online.
4.
▲
by
rxcfc
12y ago
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
5.
▲
by
rxcfc
12y ago
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.
6.
▲
by
rxcfc
12y ago
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 :)
7.
▲
by
rxcfc
12y ago
Agreed. And I suspect Ember can get closer than that, if not even outdo React in some cases.
8.
▲
by
rxcfc
12y ago
To be clear, while we're using Handlebars syntax, the underlying runtime is not the standard handlebars.js, but a custom version for Ember.
9.
▲
by
rxcfc
12y ago
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 dec
10.
▲
by
rxcfc
12y ago
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 reas
11.
▲
by
rxcfc
12y ago
Some information can be seen at the PR for Glimmer: https://github.com/emberjs/ember.js/pull/10501 .
12.
▲
by
rxcfc
12y ago
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.
13.
▲
by
rxcfc
12y ago
This is only meaningful if Dust has all the other features that Ember templating has.
14.
▲
by
rxcfc
12y ago
Ember still uses the Handlebars syntax, but we don't use the standard Handlebars runtime anymore.
15.
▲
by
rxcfc
12y ago
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 fo
16.
▲
by
rxcfc
13y ago
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
17.
▲
by
rxcfc
13y ago
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
18.
▲
by
rxcfc
13y ago
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
19.
▲
by
rxcfc
13y ago
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 ru
20.
▲
by
rxcfc
14y ago
Whoops, I misread.
21.
▲
by
rxcfc
14y ago
You weren't coming to HN to find real discourse were you? :)
22.
▲
by
rxcfc
14y ago
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.
23.
▲
by
rxcfc
14y ago
Did you read the whole forum thread? We are planning to address his complaints.
24.
▲
by
rxcfc
14y ago
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.
25.
▲
by
rxcfc
14y ago
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'
26.
▲
by
rxcfc
14y ago
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.
27.
▲
by
rxcfc
14y ago
I think it just shows that HN likes controversy. Which is news to no one :)
28.
▲
by
rxcfc
14y ago
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
29.
▲
by
rxcfc
14y ago
You're right, this should have specifically been in response to the post that was expressing frustration with Trek.
30.
▲
by
rxcfc
14y ago
Moved to the correct thread per @kbenson's response
More ›