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

81–90 of 113 posts

Re: Ember.js is driving me crazy

#81

Post by machty »

thatthatis wrote: post #76
machty wrote: post #51

Earlier quoted context omitted.

It might not be so much a genius vs non-genius thing so much as your particular app not needing the heavyweight app-state management that Ember provides. It's worth pointing out that the Ember core team has been approached by the React core team with the intent of unifying React's view layer with Ember's application state management, which is a major component of what Ember offers relative to other frameworks. If you…

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 :)

Re: Ember.js is driving me crazy

#82

Post by aryastark »

hobo_mark wrote: post #53
oinksoft wrote: post #14

Earlier quoted context omitted.

The mental effort required to find and pull the old code is far greater than that required to toggle a code comment, or just the line using that code. The author rightly points out bad behavior by Ember: Unused code should not affect program behavior.

In this day and age, why isn't there an automated way to keep file history? (like Dropbox does, but locally and with a decent interface) I am looking for something like that for Linux and my (admittedly short) research didn't turn up much.

Looked at versioning file systems? (http://en.wikipedia.org/wiki/Versioning_file_system#Linux). They've been around for awhile. Can't say why we don't have any mainstream system-level filesystem yet, though.

You may also want to check out FUSE (http://en.wikipedia.org/wiki/Filesystem_in_Userspace). Something on top of git may already exist. If not, it wouldn't be too difficult to create something like that.

Re: Ember.js is driving me crazy

#83

Post by thedufer »

mightybyte wrote: post #40
JoshTriplett wrote: post #25

Earlier quoted context omitted.

> Deleting the code and relying on source control removes the issue from top of mind. That's the goal. Your top of mind is very limited; use tools like version control to help you conserve it. > Also, it will require more work to bring back later. Then you need better version control. You can either grab the reverse diff from the commit removing it and apply that (possibly with conflict resolution against more recent…

> Your top of mind is very limited; use tools like version control to help you conserve it. Seeing a commented block scroll by doesn't waste top of mind. And if you really don't want to see it editors have something called code folding. > Then you need better version control. Have you ever tried searching a version history with thousands of commits to find a piece of code that you think you might have written awhile…

> Have you ever tried searching a version history with thousands of commits to find a piece of code that you think you might have written awhile back, but you can't remember enough details about to come up with a good search term?

I find that a `author(..) and file(..)` (hg) query gets you at least 90% of the way there if you have things split into a reasonable number of files. From there, running through a few guesses about search terms or even scanning the commit messages is pretty feasible. Date ranging can help, too.

There's so much data in source control - don't navigate by just commit messages.

Re: Ember.js is driving me crazy

#84

Post by ebryn »

Hey, I'm Erik, an Ember.js core team member.

I'd be happy to help you track down the issues you came across and explain to you what is going on.

You can reach out on Freenode or Twitter, I'm @ebryn. Otherwise, email me at erik.bryn -at- gmail.

Re: Ember.js is driving me crazy

#85

Post by tomdale »

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 this case, the author didn't actually comment out the code; he left it in place, assuming it would not affect the app when in fact it did.

Re: Ember.js is driving me crazy

#86

Post by thedufer »

mightybyte wrote: post #63
mattmanser wrote: post #47

Earlier quoted context omitted.

Your half-implemented feature will never, ever make it into live code. Ever. Just delete it, you commented out code leaving scum. We all hate you. And you smell. But seriously. Never commit commented out code. It's a cardinal sin and massive code smell. Never leave YAGNI, but maybe one day, hooks in code. Just delete it. It will never make it live and when someone actually comes to do that feature they'll usually hal…

This wasn't a half-implemented feature. It was a fully implemented and debugged feature. I was experimentally removing it in favor of a different approach and didn't want to have to go dredging through source control or reinvent and debug it later if I decided we needed it.

"dredging"? It sounds like you aren't very familiar with your tools. Commit, delete the code, commit. Now you're a rollback/backout away from getting it back.

Re: Ember.js is driving me crazy

#87

Post by camus2 »

thatthatis wrote: post #27
al2o3cr wrote: post #7

" but at some point I decided that the widget was no longer needed, so I commented out the widget's markup" SOURCE CONTROL, DO YOU SPEAK IT? In all seriousness, this is a major peeve of mine - the time that you're most confident that code can be deleted is when you're removing the pieces that depend on it. If the deletion really turns out to be wrong, you should be able to restore the code from source control. If you…

I was expecting an ember vs angular holy war in the comments, not a when-to-comment-out-vs-delete holy war.

Ember vs angular ,it's so 2013...

Re: Ember.js is driving me crazy

#88

Post by mixonic »

nathanhammond wrote: post #75

Zombie Code Apocalypse: I would love to help you identify what it is that caused that problem. I don't suspect that it is an issue with Ember itself, though note that the Ember resolver will load code when you store it in `App.Foo(Controller|View|Route|...)` if that code is "needed" (say, by visiting the Foo route). So, unless you commented out the entire declaration it is entirely possible for that code to execute.…

Just a nit for accuracy, but the implication that "the Ember resolver will load code when you store it in App.Foo(Controller|View|Route|...)`" eagerly is not true. I believe the author use an HTML comment to comment out his usage and not a handlebars comment, so the code was still being run (just hidden behind html comments).

But regardless, Ember will not load everything in the App. namespace blindly- it will wait until that item is required, then try to load it.

This is your helpful Ember #protip for the day. :-p

Re: Ember.js is driving me crazy

#89

Post by marknutter »

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 making a lot of assumptions about how routes are handled, constructed, and organized. This is great if you can assume that an app's routes will be written in a very traditional way, aka one route per page. It breaks down however when you want to tie different routes to two or more components on the same page (i.e. two different tabbed sections). One concern per route makes perfect sense on the server when serving a traditional stateful web application but it often doesn't make sense for rich desktop-style applications (which is probably why Photoshop doesn't have urls).

Data persistence on the client is another area I feel hasn't been nailed down in general and thus can't support a lot of opinionated assumptions. Should data be persisted at all? Ember caches data from all requests to the server in a "store", but it's not clear how you keep that cache up-to-date. Perhaps you could use websockets to keep resources current but at the time I was using Ember there wasn't a clear, well supported way to do that. I think the jury is still out on whether we should be duplicating our schema on the front-end at all but Ember-Data has gone all-in on mimicking ActiveRecord. Again, the dust has not settled in a lot of areas of the front-end development world as far as I'm concerned so I don't feel comfortable with these decisions being made for me.

I tend to lean toward convention over configuration. On the server I'm a big Rails fan but I feel like it's solving problems that aren't moving targets. On the front end I prefer Angular because it solves the main headaches (two-way binding, testability, modularity) of front-end development without being too opinionated about the stuff we haven't reached consensus on.

Post reply on HN