Great post.<p>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.<p>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.<p>Surprisingly to many, both work just great in Discourse; try it out if you don't believe me.<p>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].<p>[1] <a href="http://words.steveklabnik.com/emberjs-and-accessibility/" rel="nofollow">http://words.steveklabnik.com/emberjs-and-accessibility/</a><p>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.<p>[2] <a href="https://twitter.com/tomdale/status/300653212472598528" rel="nofollow">https://twitter.com/tomdale/status/300653212472598528</a><p>[3] <a href="https://twitter.com/tomdale/status/300653225785311232" rel="nofollow">https://twitter.com/tomdale/status/300653225785311232</a><p>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.
The only issue I take with this is:<p>> <i>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.</i><p>For certain super-rich highly complex webapps, sure -- and believe me, I've done those.<p>But most of the time, it's actually quite a reasonable way to go about things. Most of the time, your DOM/HTML/code <i>is</i> 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.<p>The kind of blanket assetion that "<i>congratulations, your code is now spaghetti</i>!" really comes across like a bad case of "a little knowledge is a dangerous thing". Or maybe just big-time exaggeration...
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.<p>Try go to a thread now. Not the list of threads, but actual forum thread on the meta.discourse.org forum. (e.g. <a href="http://meta.discourse.org/t/welcome-to-meta-discourse-org/1/23" rel="nofollow">http://meta.discourse.org/t/welcome-to-meta-discourse-org/1/...</a> 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?<p>EDIT: EvilTrout has a good response:<p>"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.<p>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.<p>Google can see it and index it, we've confirmed by searching post launch.<p>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 ;)"<p><a href="http://news.ycombinator.com/item?id=5198934" rel="nofollow">http://news.ycombinator.com/item?id=5198934</a>
"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"<p>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.
The bigger question, I hope someone will answer is : Why Discourse?<p>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).<p>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?<p>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)?<p>Edit:
Should have read the FAQ first ;) So my Lynx and text-to-speech users are out of luck.
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?
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.<p>Does anyone else have experience with both frameworks?
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.
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 <a href="http://www.youtube.com/watch?feature=player_detailpage&v=eJZx9c6YL8k#t=1978s" rel="nofollow">http://www.youtube.com/watch?feature=player_detailpage&v...</a>
We have an Ember based application that includes a report display with about the same amount of data as the Discourse topic list.<p>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?
Very interesting post!<p>"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."<p>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.
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.<p>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.
Great post.<p>I think it's unfair picking on Angular for obtuse docs when Ember has the same problem though.<p>The PeepCode Ember video was a big step towards Ember being accessible to all; it's still <i>really difficult</i> to use compared to Backbone etc and I don't think experienced devs close to the framework appreciate this enough.<p>Also, Discourse is a phenomenal learning resource, thanks so much for that :)
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.<p>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.