Haven't used Ember.js myself (though have been wanting to for quite some time). This struck a cord with me though:
> 8. JavaScript
> Writing most of your app in JavaScript is simly[sic] not fun. JavaScript is known for being designed in 10 days. Ruby is known for being designed for developer happiness - which sounds better to you?
---------
I don't think it's fair to compare Ruby and JavaScript because they are fundamentally used for different problems. You can never write Ruby for client-side, so why is it being compared? You have to use JavaScript (or CoffeeScript, or what have you), therefore you use it to get the job done.
In essence, complaining why use JavaScript is not a fair reason against Ember. It's more of a reason for: "Why go with a client-side JS framework in general", rather than specifically Ember. This was the only point I wanted to make regarding the article.
Aside from that, I definitely appreciate the learning and will take these reasons into consideration if/when I decide to use Ember.js. Hopefully one of the core team members can explain more about the other reasons mentioned.
I've had better experience with Angular, though some of the complaints apply to Angular too (e.g., silent errors in templates). Recently I started using Facebook's React framework, and so far it's worked well for me. You'll probably end up writing more code than you would in Angular/Ember, but that's because React is only a view framework (so it frees you up to use vanilla JavaScript for other things, like ajax, routing, etc.). React is also much faster than Angular because of its virtual DOM patching technique.
But my favorite part of React so far is that view logic is grouped together with the views. This goes against the "best practice" of separating views and logic, but I think it makes navigating the codebase easier. You want to learn everything about how some custom view widget works? It's all in one file, rather than spread across app/assets/javascripts/widget.js and app/views/widgets/widget.html.erb. No directory hopping needed to learn how the widget works.
I am shocked how highly this is rated on here. You used Ember for the first time and thought you moved slower? That is...expected. It's called a learning curve. The first time I wrote a Rails app I worked much slower than writing Sinatra.
The graph? I'm surprised you didn't break "Ember Template" into "Regular Expressions", "String Concatenation", and "Returning Variables" to further your point. Why does "Rails" have one box?
I really hope I'm not missing some joke and making a fool out of myself right now.
The diagram comparing the stacks feels pretty unfair to me. You have one box for "rails", but then break apart ember's stack into "models", "controllers", "routes", etc. a similar diagram could be drawn for activerecord, actioncontroller, etc - right?
What difference would it make? The Rails box is the same for both columns. He could have ommitted it and just add a generic "backend framework" box with the results being the same.
I considered adding breaking that down further; it's definitely more complex than that. The thing is rails "models", "controllers", "routes" are still there in the Ember version. The point is added concepts, structure, files, etc. with Ember.
This is an architecture preference disguised as a tool review. It should be called "Reasons why I don't like client-side web programming and prefer to work with server-side logic".
The title and some of the critics are unfortunate but this post nevertheless is hitting a soft spot for me. I've been through backbone & angular and I'm starting to question the necessity of a full blown framework when all I want is some structured js for each page/resource.
More fundamentally it seems the offer on js libraries are either tailored to eye-candy widgets or the big SPA. Nothing has popped in my radar as proposing an incremental step from server side HTML to MV([A–Z]) Dom/json manipulation which entices you to almost build the app twice.
What I'd really like to see rather than a client-side-solution is a server/client migration path from html to spa without being tide to one or the other
The links he included (see below) bring up the same concerns....
> Our development speed was about 1/3 of what it would have been with normal rails development.
How much experience did you already have with Rails? I would expect that learning a new tool would take longer than using one you are already intimately familiar with.
> Additionally, using Ember really increased the layers in our stack.
I don't think this is that much different than Angular.js. That would also add a significant number of components to the stack.
> Writing most of your app in JavaScript is simly not fun.
Typos aside, this is hardly a downside of Ember.js. I work in JavaScript full time (node.js), and while it has its gotchas, I really appreciate the functional nature of the language. I was writing some C# yesterday and I was disappointed at how hard it was to do function passing and function composition compared to JavaScript.
It's good for the Ember.js ecosystem to understand the short comings of the framework, but I don't think it's particularly useful to say "Don't use this tool because...". The fact that people DO use the tool means that some people do find value in it.
One of the complaints is that there isn't enough sample code posted, yet this post didn't provide any sample code of their issue or their solutions. Doing that would add more value than just saying "Don't use Ember."
The deep-linking example comes across to me as an issue of setting up initial state. Loading those other routes first either loads data or modifies the state of the application in a way that is required to display that route.
(or the author doesn't understand the difference between example.com/path/to/route and example.com/#!/path/to/route, but seeing as it "works 50% of the time" it's probably not this)
Hi there. I omitted the hashbang just because I find it ugly.
> Loading those other routes first either loads data or modifies the state of the application in a way that is required to display that route
That should be a non-issue as far as I understand, because visiting a nested route causes the parent route code to be executed first. Hence, the confusion.
Note how all of those Users*Route classes are all siblings rather than in parent-child relationships. Also note that if you're sharing controllers, they won't pass through Route.setupController on the sibling routes because those routes aren't run.
I agree that it's probably user error in this case, but also am very surprised this isn't covered better in router documentation. I've run into this problem many times and there's still no authoritative source on how to do it properly.
Just to be clear: I'm not apologizing for Ember.js. There are lot of warts, and having actually built things in both Ember.js and Angular.js, I would have to say that I much prefer Angular.js.
For example, "Silent Errors" is spot-on. One example of an error (technically Ember-Data, but they are pretty much joined at the hip):
1. Save data for a particular model.
2. The data actually gets sent to the API and saved.
3. The API returns the updated model data.
4. Ember.js fails to load the updated data.
Turns out that the model was created with `store.createRecord('ModelName')` instead of `store.createRecord('modelName')`. Adding the capitalization to the first letter failed to raise any errors and worked in all but one place in the code. This took me a couple of hours of basically debugging Ember-Data internals (and even thinking that I had found a bug in their data loading) to figure this out (which was also difficult since some of the key methods are only generated at run-time so it's difficult to search the codebase for them).
Actually, it does have one use. If you're a recent grad or new to the industry, pay close to attention. Don't be like this guy.
Before you envelope yourself in the comfort of frameworks and libraries, learn how to poke around the internals and understand the underlying architecture. Remember that these are tools written by humans just like you. They'll have bugs. Performance problems. Maybe an edge case the creators haven't thought of. And sometimes you'll be making the mistake.
My personal rule (YMMV) is to never adopt a framework or library unless I'm ready to open a pull request. There are obvious exceptions like databases and other huge projects. I'm specifically referring to small libraries and application frameworks for this rule.
Treating frameworks and libraries as a magical-voodoo-black-box is asking for trouble.
Moreover if you decide to write a blog post warning people not to use a framework or library, you better have some deeper technical insight to back it up. This is just rude.
Never start a real project with a deadline with a framework nobody in your team knows. Especially if you consider the language it is written in "not fun".
The same thing would have happend to some degree with any other choice.
E.G last year I nearly went insane doing a project with Django. Although I am a Python developer, the framework is extremely mature and well documented …
Hm... Django isn't hard.
Mostly the problem is caused by using a framework. Since you throw a tool at things which only needs like 5% of the whole Framework. Even if it is as modular as Django/Rails etc. it's just unnecessary.
Thats why more and more Developers love tiny Frameworks/Tools like golang/Sinatra/Flask
I totally agree with the 5%, that's why I never used Django before for a real project and preferred Flask mostly. But for this project it made sense since I'm using almost all of its documented features and some undocumented ones like model swapping plus a couple of extensions.
My point was, that it doesn't have to be hard to slow you down. Whatever framework you choose, you will get stuck at some point. A Django developer will have starting problems with Flask, glueing together the basics and choosing a folder/file layout (or changing it later), while for me, I had a very quick start with django building a prototype in no time but then got stuck a lot later on while customizing an having other opinions that the opinionated framework.
It feels like the author is not familiar with JavaScript, and is taking it out on Ember. JavaScript is a whole different environment than Ruby, not in the least part because JavaScript provides async code-entry. Maybe that would be causing the direct URLs to fail, as some global state is expected in the child pages, but isn't setup yet.
I'm no ember fan, but comparing a system that talks to a transactional database and creates html strings to one which handles low latency user interactions and syncs state with a remote service seems disingenuous.
I'm not personally a fan of ember but this article seems to paint it in a pretty unfair light. In the end he reveals that he really just doesn't like javascript so...
Since a lot of the complaints here are about bloat, complexity, and the steep learning curve, I'd recommend that anyone with similar concerns check out Mithril:
The comparison of Ember to Rails is incorrect. Rails is a serve side rendered framework. Ember is completely client-side. Pick any client side framework and you will face the same diffculties or obstacles. Deep linking breaks if you are not loading depending models.
Terrible post! I'm an Angular/Rails guy myself but this guys just doesn't know how to dig into the internals of something and figure it out. That's what really makes an engineer an engineer.
For those of us coding for a business purpose, we don't often want a library that requires digging into the internals.
Ideally, you want something simple that saves time. But sometimes you have to compromise and use something opaque that just gets the job done without forcing you to understand it.
The curiosity and intellectualism that make an engineer an engineer, in your opinion, can be toxic in a business environment. Spend a lot of time tinkering, learning cutting-edge technology, or reinventing wheels, and your deadline whizzes by. There's a delicate balance.
I only point these things out because, to many people, Ember.js (and many other libraries) are time-savers rather than something we want to deeply dive into just to use them.
Interesting post. I've been using Ember on lots of projects for about a year and a half now, and I think it's great. What this post really hits on, however, is the fact that Ember has quite a high learning curve.
After many years of developing SPAs using plain JS/jQuery, the benefits that a framework like Ember could provide were immediately clear to me. As a result, I was willing to push through this curve and subsequently reap the many rewards. For someone like the OP, however, who doesn't seem to have built many ambitious SPAs and for whom building a traditional server-driven web app is an option, I can understand why dealing with Ember's learning curve just doesn't seem worth it.
For those seriously interested in trying Ember, I would advise you not to make the mistake of confusing Ember's somewhat steep learning curve with the quality of the framework itself.
Thoughts:
> 1. Silent Errors.
These can definitely be annoying and difficult to debug, especially if you're newish to Ember.
> 2. Deep linking - unreliable.
This is probably because you're not handling your route setup properly. I ran into lots of issues with this when I was learning Ember, and although the guides do a better job explaining how this works nowadays, I do agree with you that it'd be nice if there were more real-world coding examples on the web.
It's important to be aware that the "model" hook in your routes isn't always called. When you use the {{#link-to}} helper in your templates or the `transitionTo` method in your routes, you pass in the model directly and the model hook is skipped. However when navigating directly to the URL, the route's model hook is called and is expected to resolve the model using the params from the URL.
There are also a few common gotchas that involve dealing with nested routes, but I'd have to look at your code to see what exactly is causing your routing issues.
> 3. Few libraries
If you're using Ember Data (which hasn't hit 1.0 yet), I could see pagination being somewhat of a pain in the ass. Still, I'm using Ember Data on a couple of large projects right now, and I was able to get pagination working fine in a couple of days.
If you're not using Ember Data, pagination shouldn't be harder with Ember than it is with plain JS+jQuery.
> 4. Few code examples / resources
I agree with you here. There are some good open source Ember apps that you can learn from, but definitely not enough simple code examples online. This is one of the reasons that the learning curve is so high.
> 5. Slower development
Learning something new is almost always going to be slower than going with what you know. This is especially true of Ember, which the team very accurately bills as "a framework for creating ambitious web applications" (emphasis theirs). Ember is often overkill for a lot of the apps that people need to build. However, if you're building something ambitious, Ember will save you time and headache in the long run. And once you get familiar with it, you'll be pretty speedy.
> 6. Added layers and complexity
I think your diagram comparing a Rails+Ember stack to a Rails+jQuery stack is totally misleading. You've simply taken everything in Ember and squished it into "Javascript/jQuery". If you're writing a very simple front-end app or a complex app composed of terrible jQuery spaghetti code then yeah, I guess it's an accurate diagram. But if your front-end app is actually complex and well-written, then you're going to have to spend a considerable amount of time implementing some form of glue to handing routing, templating, model state, etc on the front-end. Ember does that for you.
> 7. It restricted our design
Ember shouldn't limit your design. It seems more likely to me that you guys were new and unsure of how to use Ember to accomplish a specific goal. That said, it'd be great to hear what kinds of snags you ran into, as these would probably make for some good code examples.
> 8. JavaScript
Ember is for developing applications in JavaScript. If you don't like writing JavaScript-heavy apps, Ember is not for you. And that's okay. It's very often the case that traditional server-centric applications are more than good enough for the task at hand. But when the situation calls for building a modern and ambitious single-page application, you're stuck with JavaScript whether you like it or not, and I believe Ember is a great way to go.
> 8. JavaScript
> Writing most of your app in JavaScript is simly[sic] not fun. JavaScript is known for being designed in 10 days. Ruby is known for being designed for developer happiness - which sounds better to you? ---------
I don't think it's fair to compare Ruby and JavaScript because they are fundamentally used for different problems. You can never write Ruby for client-side, so why is it being compared? You have to use JavaScript (or CoffeeScript, or what have you), therefore you use it to get the job done.
In essence, complaining why use JavaScript is not a fair reason against Ember. It's more of a reason for: "Why go with a client-side JS framework in general", rather than specifically Ember. This was the only point I wanted to make regarding the article.
Aside from that, I definitely appreciate the learning and will take these reasons into consideration if/when I decide to use Ember.js. Hopefully one of the core team members can explain more about the other reasons mentioned.