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

Ember.js is driving me crazy

softwaresimply.blogspot.com

Post reply on HN
Print view View original

101–110 of 113 posts

Re: Ember.js is driving me crazy

#101

Post by rxcfc »

marknutter wrote: post #89

I've worked on large javascript applications written in Ember, Angular, JavsacriptMVC (now can.js), and jQuery and the conclusion I've come to is that things have not settled down in the world of front-end development enough to justify a framework as opinionated as Ember. For example, Ember relies very much on routing being handled a certain way. In fact, much of the magic in Ember comes from the fact that it's makin…

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.

Re: Ember.js is driving me crazy

#102

Post by jessep »

machty wrote: post #81
thatthatis wrote: post #76

Earlier quoted context omitted.

Where did those discussions lead? "EmberJS merges with ReactJS" seems like a pretty exciting headline.

Ember's approach to watching for changes is pretty different. Also, the Ember view layer refactor codenamed HTMLbars has yielded some extremely promising (though admittedly early/premature) performance improvements that often outperform the React equivalent. So we're open to the idea and we have much we can learn from each other but we're not going to merge in React if we can do a better job :)

For me, and I think most people who get excited about it, performance isn't what attracts me to React. It is the semantics (is that even the right word?). The nice way it lets me think about things.

It looks to me like htmlbars is handlebars emitting DOM rather than string. In that case, I think it will be missing the benefits of React. Again, though, I obviously don't understand Ember well.

Re: Ember.js is driving me crazy

#103

Post by rtfeldman »

marknutter wrote: post #89

I've worked on large javascript applications written in Ember, Angular, JavsacriptMVC (now can.js), and jQuery and the conclusion I've come to is that things have not settled down in the world of front-end development enough to justify a framework as opinionated as Ember. For example, Ember relies very much on routing being handled a certain way. In fact, much of the magic in Ember comes from the fact that it's makin…

I've found this true in general - front end, back end, you name it.

Every time I've used multiple decoupled libraries instead of one large framework, things have gone fine. If a particular library isn't working out, I just swap it out for an alternative (or roll my own, if worst comes to worst) and continue building.

Every time I've used a large framework, I've ended up with major buyer's remorse. There's always at least one particular piece (like routing in your case) that's a bad fit, but everything is so tightly coupled, I can't just swap out the offending component without causing problems elsewhere...so I often end up accepting a bad fit.

For me, the productivity gains of big frameworks have always been outweighed by drawbacks as soon as I hit nonstandard use cases. I always find myself wishing I'd used multiple smaller, decoupled libraries instead.

Re: Ember.js is driving me crazy

#104

Post by rxcfc »

orochi235 wrote: post #33

I'm an experienced web developer (Backbone is my preferred framework) whose team is migrating to Ember. It has its high points, but on the whole, it's been driving me nuts. Ember, like most modern frameworks, represents itself as MVC. But it's more like MVCLCTMRA (model-view-controller-layout-component-template-mixin-router-application, if you're following along at home). There are just so many moving pieces, and the…

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.

Re: Ember.js is driving me crazy

#105

Post by rxcfc »

ufo wrote: post #69

Can anyone who is more experienced with ember help explain what was going on in those two weird examples in the OP? (Commenting a widget affecting another one and setting the "bar" field also changing the value of "foo" field)

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.

Re: Ember.js is driving me crazy

#106

Post by praxxis »

ef4 wrote: post #37
strager wrote: post #19

Earlier quoted context omitted.

I don't see how this relates to the problems posted in the article. How does the lack of Proxy make the behaviour less confusing? Where does the author mention asynchronous behaviour and JavaScript's run loop?

I was just commiserating and sharing my own experience. The problems posted in the article are really hard to judge because the author doesn't actually explain what happened. In the first example, he doesn't try. Fair enough, it's a judgement call on whether to spend time understanding what happened. Personally, I would consider it high priority, because otherwise you have no assurance that the same problem isn't bit…

I think you correctly identified the second problem, an example was posted below in a comment: http://softwaresimply.blogspot.com/2014/01/emberjs-is-drivin...

Re: Ember.js is driving me crazy

#107

Post by marknutter »

rxcfc wrote: post #101
marknutter wrote: post #89

I've worked on large javascript applications written in Ember, Angular, JavsacriptMVC (now can.js), and jQuery and the conclusion I've come to is that things have not settled down in the world of front-end development enough to justify a framework as opinionated as Ember. For example, Ember relies very much on routing being handled a certain way. In fact, much of the magic in Ember comes from the fact that it's makin…

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…

I'm not proposing web apps don't us URLs. What I am saying is that the lines are being blurred as to when a web app should use urls and when they shouldn't. When I click a tab on a nested component in a larger page, should the url route there? Should the url route change when a modal pops up? If an accordion control slides open should the url change? Not sure? Neither am I. Routing on the web is not as simple as you're implying it is.

You're right about ember-data being optional but I mentioned it because it's what we were using on the project I was on.

I guess what I meant when mentioning rails was that there's a lot less change happening on the server-side than on the client-side these days so it's easier to confidently build an opinionated framework there. It's hard to favor convention over configuration when the very platforms you're targeting don't have established, agreed upon conventions.

Re: Ember.js is driving me crazy

#108

Post by nathanhammond »

mixonic wrote: post #100
nathanhammond wrote: post #95

Earlier quoted context omitted.

I've edited it for clarity based upon my original comment. :) I actually rely on this behavior every day because the app I've built uses require.js to load values into the `App.` namespace dynamically. That being said, now that you mention it, it seems far more likely that the issue was HTML vs HBS commenting. As an aside, what is the default behavior going to be for HTML comments inside of HTMLBars templates? That s…

Oh my man, you really need to dig into the resolver! You can avoid the App. namespace entirely if you already use modules. This is what Ember-App-Kit and Ember-App-Kit-Rails already do with ES6 modules, just transpiled to AMD internally. And yeah, I'm unsure of that the behavior will be in HTMLBars. I really hope it doesn't touch logic inside HTML comments- that would be quite nice.

We started on this project using Ember 0.9.6 (though we've managed to keep up with HEAD) and much of our architecture is predicated on the toolchain choices we've made. Our first big task on our list after reaching feature-complete is to migrate to EAK, don't you worry. (We knew it was coming and adopted require to make it easier to migrate.)

Re: Ember.js is driving me crazy

#109

Post by iamstef »

mightybyte wrote: post #99
jairtrejo wrote: post #98

Earlier quoted context omitted.

The scary part for me is uncommenting it, because the code has been removed from normal QA and testing (automatic or manual) and you don't know what evils you are unleashing upon the world.

That's because you're not using Haskell. :) Herein lies the crux of my point. Haskell's purity and strong static types allow you to make lots of very strong assertions about what kind of evils you might be unleashing.

seems like this post should have been titled "What JavaScript(or its replacement) could learn from Haskel"

Re: Ember.js is driving me crazy

#110

Post by mightybyte »

rxcfc wrote: post #105
ufo wrote: post #69

Can anyone who is more experienced with ember help explain what was going on in those two weird examples in the OP? (Commenting a widget affecting another one and setting the "bar" field also changing the value of "foo" field)

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.

To be fair, the documentation I was linked to doesn't say anything about the 'content' property behaving this way. It only mentions 'model'.

In the second case, it seems quite reasonable to assume it knows about HTML comments and that they would behave as I expect.

Post reply on HN