Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advice On & Instruction in The Use of Ember.js

trek.github.com

Post reply on HN
Print view View original

11–20 of 72 posts

Re: Advice On & Instruction in The Use of Ember.js

#11

Post by MatthewPhillips »

railsjedi wrote: post #3

Perfect article and explanation. After having bought into Ember a couple months ago and using it heavily, it's been really hard to express to others why it feels so revolutionary. Ember really changes JS development in ways that the other frameworks don't even attempt. And in a way this hurts it in the perception of developers, since it more often than not is just tagged as "too complicated" or "too much to learn". T…

But Rails was built for a different world, so trying to recreate what made Rails nice in the browser feels like an answer searching for a problem. Client-side JavaScript frameworks should be compared to UIKit and the Android SDK, not to Rails, which was only interested in routing, fetching, and rendering. Giving me code organization without giving me structure is only helping with a tiny sliver of the problem.

Re: Advice On & Instruction in The Use of Ember.js

#12

Post by railsjedi »

MatthewPhillips wrote: post #11
railsjedi wrote: post #3

Perfect article and explanation. After having bought into Ember a couple months ago and using it heavily, it's been really hard to express to others why it feels so revolutionary. Ember really changes JS development in ways that the other frameworks don't even attempt. And in a way this hurts it in the perception of developers, since it more often than not is just tagged as "too complicated" or "too much to learn". T…

But Rails was built for a different world, so trying to recreate what made Rails nice in the browser feels like an answer searching for a problem. Client-side JavaScript frameworks should be compared to UIKit and the Android SDK, not to Rails, which was only interested in routing, fetching, and rendering. Giving me code organization without giving me structure is only helping with a tiny sliver of the problem.

Sorry, I just meant compared to Rails in terms of impact. Ember is nothing like Rails architecturally. There's a good comparison here: http://emberjs.com/guides/ember_mvc/

So yeah. Ember's problem is convincing people there's a problem (hint: there definitely is).

Re: Advice On & Instruction in The Use of Ember.js

#13

Post by trek »

fusiongyro wrote: post #4

Here's my petition for the site to join the contrast rebellion: http://contrastrebellion.com/ The page is basically unreadable in FF 7.0.1 on RHEL 5.3. I realize light grey on white with a really thin font is dead sexy on your Mac (probably looks great on my home computer as well) but it's useless to me at work.

I agree. You should take this up with the Github page folks, specifically https://github.com/orderedlist. It's his template.

Re: Advice On & Instruction in The Use of Ember.js

#15

Post by tomdale »

inetsee wrote: post #14

Can anyone tell me whether a website built with Ember.js's default settings suffers from the same readability problems with font and contrast? If so, that tells me that I probably won't want to invest any time in learning to use Ember.js.

Is this a serious question, or just snark? Ember.js does not ship with a default stylesheet—it's up to you to style. It just generates plain HTML.

Re: Advice On & Instruction in The Use of Ember.js

#16

Post by MatthewPhillips »

railsjedi wrote: post #12
MatthewPhillips wrote: post #11

Earlier quoted context omitted.

But Rails was built for a different world, so trying to recreate what made Rails nice in the browser feels like an answer searching for a problem. Client-side JavaScript frameworks should be compared to UIKit and the Android SDK, not to Rails, which was only interested in routing, fetching, and rendering. Giving me code organization without giving me structure is only helping with a tiny sliver of the problem.

Sorry, I just meant compared to Rails in terms of impact. Ember is nothing like Rails architecturally. There's a good comparison here: http://emberjs.com/guides/ember_mvc/ So yeah. Ember's problem is convincing people there's a problem (hint: there definitely is).

Those are implementations details, to the developer they serve a similar purpose. This is my problem with it, a web framework that gives equal weight to M, V, and C is missing the point; in the client the View is fucking everything. It is where any developer will spend the vast majority of their time; not in code organization. The frameworks and I mean this plurally, that win will be those that give structure to applications. Here's how the Android SDK provides structure to applications: http://developer.android.com/design/patterns/app-structure.h.... Web frameworks need the same thing. They should ship with HTML, JS, and CSS.

Re: Advice On & Instruction in The Use of Ember.js

#17

Post by judofyr »

Let me tell you why I don't care about Ember.js at the moment:

It's an "all or nothing"-solution. I couldn't care less about Stateful Single-Page Applications. I'll take a stateless, curlable, crawlable (remember Google?), old-style web site any time. Of course, some parts might require more dynamicness than other, and in that case it's lovely to jump to client side MVC. But it doesn't seem that Ember.js wants to play this game. Every time I look at Ember it seems that it wants to define the architecture of my application. Thank you very much, I like my stateless-ness very much!

Re: Advice On & Instruction in The Use of Ember.js

#18

Post by tgriesser »

With regards to view cleanup code in Backbone - in the github develop branch [1], the view is now a little more active in its memory cleanup. A dispose() function was recently added which removes any handlers added in the view's 'events' object, as well as any collection or model listeners where the view is passed as the third argument (callback context). This function is also called by the view's .remove(), taking care of the majority of basic memory cleanup needs when the element is cleared from the screen.

[1]: https://github.com/documentcloud/backbone/commit/3ae1af6df1b...

Re: Advice On & Instruction in The Use of Ember.js

#19

Post by erikbryn »

judofyr wrote: post #17

Let me tell you why I don't care about Ember.js at the moment: It's an "all or nothing"-solution. I couldn't care less about Stateful Single-Page Applications. I'll take a stateless, curlable, crawlable (remember Google?), old-style web site any time. Of course, some parts might require more dynamicness than other, and in that case it's lovely to jump to client side MVC. But it doesn't seem that Ember.js wants to pla…

There's nothing stopping you from having only certain parts of a page or application use Ember. Several people use this approach successfully.

See the `rootElement` property of `Ember.Application`: http://docs.emberjs.com/#doc=Ember.Application&src=false

Re: Advice On & Instruction in The Use of Ember.js

#20

Post by erikbryn »

MatthewPhillips wrote: post #16
railsjedi wrote: post #12

Earlier quoted context omitted.

Sorry, I just meant compared to Rails in terms of impact. Ember is nothing like Rails architecturally. There's a good comparison here: http://emberjs.com/guides/ember_mvc/ So yeah. Ember's problem is convincing people there's a problem (hint: there definitely is).

Those are implementations details, to the developer they serve a similar purpose. This is my problem with it, a web framework that gives equal weight to M, V, and C is missing the point; in the client the View is fucking everything . It is where any developer will spend the vast majority of their time; not in code organization. The frameworks and I mean this plurally, that win will be those that give structure to app…

Perhaps you'd be a fan of SproutCore?
Post reply on HN