
Why Discourse uses Ember.js - EvilTrout
http://eviltrout.com/2013/02/10/why-discourse-uses-emberjs.html
======
tomdale
Great post.

Client-side web applications have come a long way in the past year. In the
comments I read when Discourse was released, many people dismissed out-of-hand
rich JavaScript apps based on stale information.

For example, they assumed that infinite scrolling would mean you would lose
your place when hitting the back button. They also assumed you would not be
able to command-click a link to open it in a new tab.

Surprisingly to many, both work just great in Discourse; try it out if you
don't believe me.

Many people also held on to the belief that JavaScript apps are fundamentally
incompatible with assistive software; that one is also a common misconception
that's just not true anymore. Steve Klabnik wrote up a great overview of
it[1].

[1] <http://words.steveklabnik.com/emberjs-and-accessibility/>

A lot of people pan client-side apps as being slow and bloated and overloaded
with JavaScript. Surprisingly, they don't have more than your average full-
featured, server-side web application[2][3]. And I think Discourse proves that
you can build large apps that feel lightning-fast.

[2] <https://twitter.com/tomdale/status/300653212472598528>

[3] <https://twitter.com/tomdale/status/300653225785311232>

If you investigated building apps like this in the past and didn't think it
was ready, now is a great time to give it another shot. The tools are maturing
rapidly, and while still not perfect for every use case, we're knocking down
limitations every day. I'm excited for all the cool stuff people will build in
2013.

~~~
hcarvalhoalves
The problem is, we're trying to write desktop applications on top of browsers
which were designed for navigating hypertext documents. It's akin to writing
apps with macros inside Microsoft Word. Somehow, everybody still thinks this
is sane.

 _Something_ has to give. Either browsers just turn into JS VMs with HTTP
capabilities and get away with window chrome and the page interaction model
(aka, back/forward), or we give up on web apps. Right now, web apps are all
about endlessly duct-taping the browser together in JS to try and get a decent
UX with a new, ground-breaking framework someone released this month, but
developer productivity still sucks and polish is never quite there.

~~~
mistercow
>we're trying to write desktop applications on top of browsers which were
designed for navigating hypertext documents

I think that's a rather silly thing to say. You might as well say that
computer games are doomed because we're trying to render complex scenes using
hardware that was designed for simple calculations. Just about all successful
technology comes about through an evolutionary process, building on older
technology and morphing into new applications. When people notice this and say
"this technology was originally designed for something else! It must be wrong,
so let's reinvent it from scratch!" it usually doesn't end well.

~~~
hcarvalhoalves
> I think that's a rather silly thing to say. You might as well say that
> computer games are doomed because we're trying to render complex scenes
> using hardware that was designed for simple calculations.

We certainly aren't trying to render complex scenes using hardware designed in
1995. Browsers, on the other hand, have the same interaction model since 1995,
but we're trying to use it for a totally different intent (static vs.
interactive). I'm talking about _user experience_ here.

> When people notice this and say "this technology was originally designed for
> something else! It must be wrong, so let's reinvent it from scratch!" it
> usually doesn't end well.

It's not about reinventing from scratch, it's about actually evolving the
browser. It's semi-broken currently. Mobile made the problem even more
apparent (show me a useable mobile web app).

~~~
blowski
Can you give specific examples of what is broken and how you would fix it?

~~~
randomdata
Broken may not be the best description. People are managing to make it work
just fine for the most part.

Unnecessary may be a better way to put it. What benefit do we really gain from
doing all kinds of crazy DOM manipulations to return to what effectively
amounts to a framebuffer and a few built-in drawing functions, emulating what
we've been able to do on the raw hardware for decades?

"It exists" seems to be the best justification at this point. And that is a
pretty strong justification, don't get me wrong. There is simply nothing
better for on-demand distribution of network applications.

However, if we were to rebuild the model from scratch, I see no reason why we
would want to include HTML as the basic building block. HTML rendering would
more appropriately be an application built on top.

------
crazygringo
The only issue I take with this is:

> _So maybe we add another data-liked="true" attribute. ACK! Just typing this
> all out is giving me a headache!. Congratulations, your code is now
> spaghetti, your data is strewn out in the DOM and your logic is tied to a
> particular layout of HTML elements._

For certain super-rich highly complex webapps, sure -- and believe me, I've
done those.

But most of the time, it's actually quite a reasonable way to go about things.
Most of the time, your DOM/HTML/code _is_ tightly coupled, and uncoupling it
just adds complexity. And it's only spaghetti if you let it be -- there's
nothing inherently spaghetti-like about using data- attributes with jQuery
events and simple DOM manipulation, if it accurately and intuitively reflects
user actions and site usage. It's really only when you get to multiple views
of the same data, and data that changes in real time, that the game changes.

The kind of blanket assetion that " _congratulations, your code is now
spaghetti_!" really comes across like a bad case of "a little knowledge is a
dangerous thing". Or maybe just big-time exaggeration...

------
meric
If you use Ember.js, and store the JSON data in the HTML body, how will search
engines crawl your site properly? In the codinghorror blog post on Discourse,
it says the author found out forums were valuable because he frequently
stumbled on them using search engines.

Try go to a thread now. Not the list of threads, but actual forum thread on
the meta.discourse.org forum. (e.g. [http://meta.discourse.org/t/welcome-to-
meta-discourse-org/1/...](http://meta.discourse.org/t/welcome-to-meta-
discourse-org/1/23) not sure how long this link will last) Search for some
text from the forum post in the HTML source. It isn't there! How can you find
this information on search engines then? Can search engines be reliably
expected to run javascript now?

EDIT: EvilTrout has a good response:

"Actually we aren't using server side handlebars rendering for the Google
aspect, although that's something we considered! We're using it for more
boring stuff like our Oneboxes.

Our site is indexable by Google and it doesn't do much fancy. On certain URLs,
we generate a small HTML view of the content in the <noscript> tag. You can
see this by viewing source or disabling JS in your browser. It's just a simple
ERB template in Rails, and uses the same object graph that we serialize via
Active Model Serializers.

Google can see it and index it, we've confirmed by searching post launch.

As time goes on we'll probably work more on it to make the SEO even better. As
you can imagine it was tough to do when we were in stealth mode ;)"

<http://news.ycombinator.com/item?id=5198934>

------
mrgordon
"Yehuda Katz has done amazing work on Rails 3 and Bundler. When he tells me
that he’s not going to abandon Ember.JS, I believe him, because he has a track
record proving so"

Uhhh nothing against Yehuda but I strongly object to this as someone who got
burned badly with Merb. I've also seen his Rails.app Kickstarter project
languishing and how many versions of SproutCore/Amber/Ember have there been
that are now completely obsolete? I love a lot of his work but to say he has a
track record of not abandoning projects goes against the facts.

~~~
devinus
This is complete FUD. First of all, I'm not familiar with Merb but didn't it
merge with Rails? Regarding Rails.app, how is it languishing? Yehuda has given
status updates[1] and code is on Github right now[2]. SproutCore continues to
be developed to this day[3]. Ember was briefly named Amber for about a day.
What are you talking about?

[1]:
[http://www.kickstarter.com/projects/1397300529/railsapp/post...](http://www.kickstarter.com/projects/1397300529/railsapp/posts/393849)

[2]: <https://github.com/tokaido>

[3]: <https://github.com/sproutcore/sproutcore>

~~~
jamie_ca
As someone who worked on a Merb app fulltime for about 4 years (before merb
1.0 through to well after rails 3 released) it's more accurate to say that
Rails got rearchitected with some of the good ideas Merb had on the backend.

When the plan was originally announced, Yehuda blogged
(<http://yehudakatz.com/2008/12/23/rails-and-merb-merge/>):

    
    
        In particular, we will do Merb releases with deprecation 
        notices and other transitional mechanisms to assist 
        developers in tracking down the changes that will come 
        between Merb 1.x and Rails 3. Expect a number of interim 
        releases that get incrementally closer to Rails 3, and 
        expect parts of Merb (most notably the helpers) to be 
        ported to run on Rails 3 in order to further reduce 
        friction.
    

This very specifically did not happen, and a lot of people are stuck on Merb
or had a painful migration. Of note, Rails 3.0's first beta was released Feb 4
2010 (just over a year after the announcement), and 3.0.0 final was August 29.
Merb had a 1.1 prerelease Feb 20, and the last version (1.1.3) July 10. Since
then Merb has been dead.

Again Yehuda:

    
    
        You will not be left in the cold and we’re going to do 
        everything to make sure that your applications don’t get 
        stuck in the past.
    

Now I'm sure as part of the merb community I can take some small part in blame
of this, but nobody, not merb developers, not rails developers, not merb users
(to the best of my knowledge) wound up putting any serious stock into
providing anything resembling a migration plan. Which is a shame.

------
eksith
The bigger question, I hope someone will answer is : Why Discourse?

Not putting down the software, but I did look at the about page and didn't get
much convincing. Also, even though I'm not mainly a PHP dev, the assertion
that "ancient, legacy PHP/MySQL code bases" doesn't apply to bbPress or
Vanilla (or at least I hope not, I haven't really looked at the code in a
while).

Also, and this may be what sells it to me, can I use it comfortably if I'm
disabled? I've built some discussion forums for sites that cater to people who
have difficulty navigating cluttered environments (some have suffered strokes
or other brain injuries) and some who are legally blind. Can they replace
their forums with Discourse?

Other forums, even the crappy legacy code ones, still have real HTML links
that can be browsed. Can I use it while having JS disabled (let's say I'm some
privacy freak)?

Edit: Should have read the FAQ first ;) So my Lynx and text-to-speech users
are out of luck.

~~~
steveklabnik
> can I use it comfortably if I'm disabled?

tomdale posted a link in a comment above, but yes, you can. I wrote about
using Discourse with screenreaders here:
<http://words.steveklabnik.com/emberjs-and-accessibility>

~~~
eksith
Accessing content and having a voice are not the same. As sams99 points out,
some users still won't be able to communicate without JS.

~~~
steveklabnik
Yes, some users that choose to turn of JavaScript or that use old screen
reader software that works with JavaScript.

My point is that (at least) anyone with a computer running OS X has a screen
reader that works just fine with JavaScript heavy sites.

------
mck-
Thing I didn't like about Ember is how vastly different the 1.0 prerelease is
from the previous version, resulting in a lot of SO solutions that only work
if you have the right version. Guides and tutorials out there are rather
scarce, despite the size of its community.. Perhaps that has changed in the
last few months?

~~~
csallen
I started learning Ember a few days ago, and this has been my experience.
There's a serious lack of up-to-date guides and resources for support out
there.

The official guide was decent. It does an amazing job covering everything it
attempts to cover. My problem is with the things it _doesn't_ cover.
Specifically, I'd like it to be more practical by answering the question: "How
do I get started immediately?" That means going into more detail about things
like Ember Data, the ember-rails gem and other language/framework-specific
details, etc.

Personally, I'd love to see an up-to-date tutorial for setting up a very
simple Ember app with Rails or whatever. I find guides like that to be the
most effective at getting people up to speed with the necessary basics.

~~~
kaliblack
I'm in the same boat as you, recently starting to learn Ember. The tutorial
that Brian Cardarella created at Dockyard [1] covers creating a simple app and
is really good. There are a few other simple tutorials. I'm struggling because
all the resources I've found cover single model apps. Anyone know of any more
in-depth complex resources?

[1] [http://reefpoints.dockyard.com/ember/2013/01/07/building-
an-...](http://reefpoints.dockyard.com/ember/2013/01/07/building-an-ember-app-
with-rails-api-part-1.html)

~~~
steveklabnik
The peepcode is well worth the $12.

~~~
csallen
Thanks for the heads up. I bought it and it was useful. Still, it's woefully
incomplete. For example, no coverage of Ember Data, no use of Views, etc.
Still, it was a good starting point, and I've been able to figure out most of
the rest of it myself.

------
cleverjake
Its rather odd he mentions the docs on ember, I have actually found them to be
much less useful than the angular docs. Especially compared to a year ago,
when the project was begun.

Does anyone else have experience with both frameworks?

~~~
maxwin
I also think the biggest problem they have is the lack of good documentation.
I hope they make it top priority to create very simple and complete
documentation.

~~~
1qaz2wsx3edc
A lack of application patterns and tooling (generators, etc). A lack of a
persistent store, I found ember-data to be difficult to use and buggy, also
low on documentation. Complexity around every corner: almost everything is a
StateMachine. I'm betting it's an anti-pattern. Also views & templates,
controller and scope between layers.

Angular still faults on a couple of these. (Tooling for one)

------
wheaties
It's interesting to read a different perspective. I found AngularJS was more
in tune with how I think and like the way they decouple the code from DOM
manipulation. I'm also a big fan of \HTML based templates and having to not
touch code when I want to enable/disable some feature. That's the kind of
thing I like about small libraries like garlic.js and such.

------
patrickaljord
Eric Bidelman explains why emberjs is heading in the wrong direction when it
comes to templating while AngularJS is doing it right by implementing the
html5 web component spec, you can watch it here
[http://www.youtube.com/watch?feature=player_detailpage&v...](http://www.youtube.com/watch?feature=player_detailpage&v=eJZx9c6YL8k#t=1978s)

------
jweir
The criticism of Angular's Transclusion is spot on. I like Angular, but the
concept and description of Transclusion is very confusing.

~~~
brown9-2
I've been working my way through my first app using Angular this weekend, and
after the stellar tutorial and introduction to the framework, I have to say
the documentation becomes very technical very fast. The transclusion snippet
isn't the only part that feels like it was written by experts for experts.

~~~
gphreak
You might want to have a look at <http://egghead.io/> if you haven't already.
John manages to explain topics in simple terms and examples, usually much
easier to digest than the official documentation.

------
stevewilhelm
We have an Ember based application that includes a report display with about
the same amount of data as the Discourse topic list.

We have found giving users the ability to sort on each column to be very slow.
I noticed the Discourse doesn't have sort or filters. Was this due to
performance reasons?

------
ft_
Very interesting post!

"Additionally, we do some server side rendering, which is much easier with
string templates because we don’t have to boot a whole PhantomJS environment."

Does it mean that google is able to crawl a discourse page even when it's
using client-side mvc ? Can anybody tell me how it works ? Thanks.

~~~
EvilTrout
Actually we aren't using server side handlebars rendering for the Google
aspect, although that's something we considered! We're using it for more
boring stuff like our Oneboxes.

Our site is indexable by Google and it doesn't do much fancy. On certain URLs,
we generate a small HTML view of the content in the <noscript> tag. You can
see this by viewing source or disabling JS in your browser. It's just a simple
ERB template in Rails, and uses the same object graph that we serialize via
Active Model Serializers.

Google can see it and index it, we've confirmed by searching post launch.

As time goes on we'll probably work more on it to make the SEO even better. As
you can imagine it was tough to do when we were in stealth mode ;)

~~~
ft_
Thanks for the info!

------
someone13
Small nit: the link to the ember.js guides actually goes to the AngularJS
guides.

~~~
EvilTrout
Fixed, thanks!

------
melvinmt
The big question (for me, at least) is: why not Backbone.js?

~~~
mambodog
Lack of automatic 2-way data binding?

~~~
boubiyeah
backbone is just not worth it; May as well use vanilla JS.

------
robotmay
The greatest thing I've gotten out of Discourse so far is the fully
functional, real-world Ember app that I can use to learn Ember. So many
frameworks seem to think that a to-do application is enough of an example, but
it isn't.

I decided to start transferring an app over to Ember.js this morning, and I've
made more progress by looking at the Discourse code than I have via the
official docs.

------
jongold
Great post.

I think it's unfair picking on Angular for obtuse docs when Ember has the same
problem though.

The PeepCode Ember video was a big step towards Ember being accessible to all;
it's still _really difficult_ to use compared to Backbone etc and I don't
think experienced devs close to the framework appreciate this enough.

Also, Discourse is a phenomenal learning resource, thanks so much for that :)

------
atomical
I'm all for Ember apps but the experience on your site is jarring because the
content appears and disappears so quickly.

~~~
sams99
can you please expand on this? not following

------
jaequery
trying out discourse, pretty cool. but how do you get to the admin? and what
are the default credentials?

~~~
CornishPasty
If you're using the default db seed, then you should log in as eviltrout with
the password "password"...

Otherwise, I think you need to create a new user and edit the user manually in
the DB.

------
seivan
Yeah, the Ember docs have been given a huge boost, all that is missing is how
to glue them, I've noticed ember-rails is broken for instance.

I prefer Batman.js, but have recently been looking for leave. Slow
development, crappy performance, and generally slow on accepting pull
requests. Barely works well on mobile.

~~~
robotmay
I started building an app with Batman.js a few months ago, and I've come
across those exact same issues. The performance is a real problem as I'm doing
a lot of live updates to big-ish data sets, and it's noticeably chugging now.

