Why Discourse uses Ember.js


My guess is – that if done right – both implementations (Client-JS-MVC / Server generated HTML) will be somewhat equally fast. See Basecamp Next, for example.

If that would be true, I am not sure what speaks for JS-MVC aside from personal preference.

For me, the whole JS-MVC approach never felt right as it is just the wrong place to have your application code.


"What do you think is faster? a) Send HTML b) Use client-side MVC."

"This is mostly FUD!"

"He’s not wrong, it is slower than just getting the HTML from the server."

So what is it then? And what does an image on my website have to do with this all? Why do feel the need to ridicule me? You'd have to serve the image regardless if you use server-side or client-side HTML generation, and, more importantly, it's not needed in order to be able to view and use my blog.


Not to mention how easy is to get your site indexed by search engines. For certain web apps client-side MVC might work better (for example gmail is all a JS app), but for general web pages...


I think it would be fairer if the Ember link led not to "Getting started" but to something comparable to AngularJS directives and especially transclude feature.


Let's pick this apart, shall we?

- Rebuttal #1: "Your avatar is the same size that ember.js is". This is a non-argument, because my avatar is not required to view my blog. In fact, it's loaded asynchronously, after the HTML is rendered. And if I'd run ember.js to render my blog, I'd still have to load it. BUSTED.

- Rebuttal #2: "Discourse only requests JSON when you change views". Sure, but lots of sites don't. I also wasn't writing about Discourse in particular. PLAUSIBLE.

- Rebuttal #3: "Nobody compiles templates in production." First off, some people do. But by "compiling" I also mean parsing the JavaScript that will generate the HTML. That was slightly unclear. PLAUSIBLE (tho you still need to load & parse the JavaScript).

- Rebuttal #4: "I suppose some times you might download a list of objects and then only show ones that are active or something." Actually, that happens all the time in non-trivial applications, except if your application does nothing useful. It's a very common use case. BUSTED.

Rebuttal #5 is self-busting, as I've laid out above.

Let's tally that up. 2 of 5 plausible rebuttals, 3 busted. Looking pretty good for my "inflammatory nonsense".


For Battlelog (http://battlelog.battlefield.c... ), one of the major reasons switching to client-side rendering was improving server-side performance. I don't think that aspect of it is discussed much but rendering string templates is dog slow compared to sending JSON. Despite delegating this to the browser, the perceived snappiness for the end-user improved greatly.

All in all, for *us* it made a lot of sense due to the fact that our site is much more an app than a document.

(accidentally tweeted you before finding the comment section here :)


You used Ember.js for 2 years, and I was writing Android apps in 2002. We're both time travelers!


Whoa buddy, you're really cramping his style with all this sound logic here. if we could get back to FUD and dramatic sound bites, that'd be great.


My experience with Ember is quite different. But this was a year ago, so things might have changed significantly.

When we started with Ember a year ago the documentation was very basic and Angular was unknown. We built part of our app in Ember but later we rebuilt it using CanJS (http://canjs.us/), we just found the Ember code confusing and hard to maintain, CanJS on the other hand was an easier framework to learn and use.

We have started using Angular as well, and so far I am finding it easier to pick up than what Ember took me learn. I guess we might have picked a really bad time to learn Ember.


There's not really anything comparable to the pre-linking phase, linking phase, directive styles, linking functions, transclusions, or pre-isolate scopes in Ember.js. One nice thing about not trying to twist the DOM API into doing stuff it was never meant to do is that there is a lot of complexity we never have to surface to the end developer.


"The documentation was simple to understand"

Really? As a Ember.js newbie that started using it just one week ago, I have a completely different feeling about this. I know that you are talking from one year ago, but the article says that the guides are nice by now.

As I see it, the guides are not bad but I really miss good examples. All examples provided in them are vague, like they were made in a hurry. Besides that, they could be better if they were addressing real world problems, not situations made exclusively for the examples.

If you try to search on the web for Ember examples, you will come up with outdated app examples (even in the official ember repositories at github) that get you even more confused. Not to mention StackOverflow posts with deprecated answers. I can understand this as the framework is evolving fast, but it should be addressed at the official site with up-to-date documentation AND examples.

Can I ask you how what was your workflow when learning how to use Ember? Because I'm finding it hard and frustrating doing it with mine (working with examples, having the guides and API reference at hand and googling or looking source code when getting stuck).


Cool article.

For me by far the biggest problem with Angular is that it doesn't scale. Scopes should have been partially isolated.
As it stands, apps running on low spec devices or busy apps are either going to be painfully slow or you're going to have to put hacks in place which defeat the purpose of using a big full stack framework.
It will be worth re-evaluating it in 5+ years when Angular can leverage Object.observe :-)


Good article. I also would be interested by the answer to this question : "Why RoR?"


This has to be the best line I've heard in a while: "Congratulations, your code is now spaghetti"


Good for you. People take things so personally these days. Your application is awesome by the way. All someone needs to do is visit a regular forum, then use Disclosure. If they can't see the difference in UX right away, they are completely lying to themselves.


+1 for pineapple.io. I wrote a Backbone.js app, and had phantom.js crawl and render out the pages so the application would be SEO friendly. What was your guys solution?


I'd like to hear how you compare Backbone to Ember


Backbone is 1500lines of code, providing an opinionated way to structure your code and nothing more.


Hey buddy, please don't take it personally (just saying, since I see you already did), but I don't see any reason to come across so heavily on someone.

Maybe I'm missing some piece here; from what you said, if the only thing that Thomas did was to write the single tweet you report (ohh, how daring!), I don't really see any problem with that. do you ?

The Internet should be like an agora', an open space where everybody can express his own opinions and ideas, with proper language and respect for others. I don't see any issue in what @thomasfuchs said.

I cannot agree with him (in fact I quite disagree), but everyone is entitled to an opinion and he can have his fair points to sustain his belief (and some of them could span interesting meditation on the topic).

The tweet, as I read it here (I've no other sources of information about that other than your blog post), was just intended to spawn a thought provoking discussion on a topic. In the tweet, as you report it, there's no trace of anything like "this is the way you HAVE to do it" or other FUD inducing statements.. it's just a open-ended question, whose answer is left to the reader of the tweet, not the poster.

That said, assuming there are no other pieces of information I'm missing here (but in this case it's your blog post to be faulty because it doesn't give me the right context and perspective on the topic you're discussing about). So please forgive me if I'm going through the wrong path because of that.

I'm on the side of the "please send JSON only information to the client instead of HTML" but I'm very welcome to read from people that have different perspectives from mine and always keep an open mind. I could be doing this job for other 20 years but I would still feel like I've always something to learn from others; that's what I mostly love of this connected world we're so lucky to live in.

Internet must remain a place where everybody can give its own contribution. It's not your authority (nor mine or everyone else) to say who's entitled "to speak". You can simply disagree and/or feel compelled to express your own opinion, but maintaning the necessary respect for others opinion is paramount to build a community where people do not fear to express their thought.
The recent events happened to Heather Arthur (http://harthur.wordpress.com/2... should teach us something on that regard.



Some stuff is being indexed: https://www.google.com/search?...