4 ms·

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 ha

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.

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 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-web.html 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.
- marknutter 13y ago
  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.
rtfeldman 13y ago
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.

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 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-web.html 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.

marknutter 13y ago
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.

rtfeldman 13y ago

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.