8 ms·

Why Discourse uses Ember.js

267 points by EvilTrout 14y ago

someone13 14y ago
Small nit: the link to the ember.js guides actually goes to the AngularJS guides.
- EvilTrout 14y ago
  Fixed, thanks!
tomdale 14y ago
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/ 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 https://twitter.com/tomdale/status/300653212472598528 [3] https://twitter.com/tomdale/status/300653225785311232 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.
- deafbybeheading 14y ago
  Indeed. A few years ago, I worked in an Adobe Flex on a reporting front-end that had significant client-side complexity and required us to support relatively old browsers. We re-evaluated competing JavaScript solutions periodically, but we never found anything that was worth the gamble of moving off that platform (even though rumors of its death seemed less and less exaggerated every day). These days, I'd move to Ember or Angular in a heartbeat.
- saurik 14y ago
  My #1 problem with these kinds of applications (which I've complained about before with regards to other attempts at this, such as GitHub) is actually an issue that Discourse clearly still has in spades: it breaks the page cache (not the http cache, but the rendered page cache). The result is that when you hit "back", something you constantly do in a forum while navigating through the content, instead of nearly instantaneously seeing the old content (as it was still in memory, waiting to be moved back into view), it chugs for a second clearing parts of the DOM, then prints a "Loading..." message with a spinner as it painfully rebuilds the DOM of the previous page, and finally I get to see my content, when I only even needed it for a split second to click the next link to go to the next item I had queued. That aside, Discourse actually doesn't handle the scrolling position correctly. It isn't as bad as people like to make out offline web applications to be ("all the content is gone, and I have to start at the top again"), and it isn't even as bad as offline web applications need to be (they could be tracking the actual positions, for example; but this is even more work and is likely to cause some other problem), but even though they seem to have gone out of their way to improve this part of the experience over how most offline web applications work, it still doesn't do a good job of it: the result is that you are constantly being jarred around while attempting to navigate. I just don't think it is accurate to say these things "work just great in Discourse". Specifically, you are never going to be looking directly at a single post: you are always going to, by random chance, be scrolled to a position somewhere partway through a post. You even may purposely be scrolled partway through a long post: as you are reading it, and the scroll position is helping you keep your place. When you navigate forward and then hit back, as part of rebuilding that page based on the URL you were at, it moves you to the next full post boundary. (In practice, it is even worse than this, as it seems to chunk multiple posts together sometimes depending on what kind of activity you are performing.) They also only solved one of the problems for topics and the other problem for threads, so if you are looking at a topic and are scrolled down somewhat, there doesn't seem to be any way to throw someone (or yourself on a different computer) a hyperlink 50 pages (or even one page) deep into the topic list. So, while I appreciate your comment that people get these things wrong and have misconceptions (and I realize that it is probably somewhat your job to be the guy who makes posts like this one whenever it seems marginally appropriate ;P), I fear that you are choosing to lump in everyone who disagrees into the same bucket :(. For the record: I write HTML5 offline applications (thanks to Yehuda, who didn't warn me just how many browser bugs I'd run into while attempting to do so ;P), and I have one deployed right now with tens of millions of users. (As proof, here's my appcache manifest: http://cydia.saurik.com/ui/ios/1.1/cache.manifest http://cydia.saurik.com/ui/ios/1.1/cache.manifest ;P.) Yet, the things that people bring up about these kinds of applications really are problems if you don't address them correctly (which often involves not drinking as much of the Kool-Aid, or going through a ton of extra work to simulate something you normally get faster and for free), and I'm really not seeing how Discourse is that much different than other previous attempts at this. Now, as someone who (again) uses these technologies myself, I definitely agree with your comment about being excited for the cool stuff people will build in 2013, and I know that a lot of these issues are surmountable, and that they will be surmounted over time. However, I must say that I'm concerned, as someone who has been thinking about using Ember.js, that someone from the Ember.js team seems to be claiming that Discourse is a great example to prove that modern web applications don't have these classic problems. I would actually be much happier to read a post about how disappointed you were in the way Discourse was built, and how you feel like if they had used Ember more appropriately they would have gotten a better result, as you actually have solutions for some of these age-old problems that the people who built this specific website ignored ;P.
cleverjake 14y ago
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 14y ago
  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 14y ago
    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 14y ago
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.
jweir 14y ago
The criticism of Angular's Transclusion is spot on. I like Angular, but the concept and description of Transclusion is very confusing.
- brown9-2 14y ago
  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 14y ago
    You might want to have a look at http://egghead.io/ 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.
  - slmt 14y ago
    I haven't gone through all the egghead.io tutorials yet, but I suspect transclusion is addressed in one of the screencasts.
  - jonny_eh 14y ago
    The learning curve definitely hits a trough at a certain point but you'll get through. It's totally worth it, I'm glad I stuck with it.
- methehack 14y ago
  Picking on transclusion seems really unfair. It's a well known rough spot in the docs and has been addressed in a bunch of places outside the formal docs that aren't hard to find. Plus, you can do tons with the framework without touching on it at all. To quote it, as the article does, as if its typical of the framework is disingenous. IME, the angular docs are way easier to understand than the ember docs and they're more accurate too. I've tried twice with the ember docs, and yes recently, and both times I gave up in eye-rolling wtf frustration. I'd love to use the framework, but there's only so far I'm willing to travel barefoot. The thing that bothers me most about this whole ember vs angular thing is that there seems like a crypto-subtext here. I'm not sure what exactly is going on but there's definitely an "open source mafia" versus "big corporate google guys" thing happening. I think, maybe, the fear from the open source mafia end is that google is going to cram deep support for angular into chrome -- this is not insane and would prolly make sense technically if not for those pesky standards -- and that ultimately this is going to do other frameworks a disservice. Wild speculation alert, okay, but still some politicizing of the the debate is definitely flying around here. I'd be happier if it were out in the open.
ft_ 14y ago
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 14y ago
  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_ 14y ago
    Thanks for the info!
seivan 14y ago
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.
- mixonic 14y ago
  I'm using Ember-Rails every day, and hundreds of others must be as well. If it's broken for you, please create an issue! I think I'm on master as of two weeks ago and sailing smoothly.
- robotmay 14y ago
  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.
eksith 14y ago
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.
- sams99 14y ago
  You get a very basic view with non js, which gives you most of the information but does not allow you to contribute anything to the sites. This is mainly done for search engines.
- steveklabnik 14y ago
  > 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 http://words.steveklabnik.com/emberjs-and-accessibility
  - eksith 14y ago
    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 14y ago
      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- 14y ago
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 14y ago
  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 14y ago
    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-ember-app-with-rails-api-part-1.html http://reefpoints.dockyard.com/ember/2013/01/07/building-an-...
    - steveklabnik 14y ago
      The peepcode is well worth the $12.
      - kaliblack 14y ago
        Perfect. That's exactly what I need. Thanks.
atomical 14y ago
I'm all for Ember apps but the experience on your site is jarring because the content appears and disappears so quickly.
- sams99 14y ago
  can you please expand on this? not following
deleted 14y ago
[deleted]
mrgordon 14y ago
"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 14y ago
  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/posts/393849 http://www.kickstarter.com/projects/1397300529/railsapp/post... [2]: https://github.com/tokaido https://github.com/tokaido [3]: https://github.com/sproutcore/sproutcore https://github.com/sproutcore/sproutcore
  - mrgordon 14y ago
    Merb and Rails did merge, but that doesn't mean any reasonably sized Merb codebases had any hope to migrate. It's a different framework with a different ORM. All those developers that followed Katz early on got burned when he joined Rails core. I do believe Rails.app will be released and Katz has recently given an update (it's dated January 27) but the first dozen comments at http://www.kickstarter.com/projects/1397300529/railsapp/comments http://www.kickstarter.com/projects/1397300529/railsapp/comm... will show that there has been some community concern that they bought into vaporware/Ember.js. Those comments went on from November 15 to January 25 before a Hacker News post solicited a comment. In regards to SproutCore, I was referring to SproutCore 2.0 which became Amber which became Ember.js. Ember.js seems to be coming together nicely, but we are already supporting 4 completely incompatible versions of it. Admittedly we are still at ember-1.0.0-pre.2 and I'm sure the APIs will eventually solidify, but it feels like even new patch versions have been radically incompatible. Definitely excited to see Rails 4, Ember 1.0, etc. for the record. I just have spent a significant amount of time cleaning up the messes of abandoned Merb codebases so I couldn't help but point out that Katz's legacy has been, at best, mixed here.
crazygringo 14y ago
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...
stevewilhelm 14y ago
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?
jaequery 14y ago
trying out discourse, pretty cool. but how do you get to the admin? and what are the default credentials?
- CornishPasty 14y ago
  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.
robotmay 14y ago
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.
patrickaljord 14y ago
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=eJZx9c6YL8k#t=1978s http://www.youtube.com/watch?feature=player_detailpage&v...
meric 14y ago
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/23 http://meta.discourse.org/t/welcome-to-meta-discourse-org/1/... 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 http://news.ycombinator.com/item?id=5198934
melvinmt 14y ago
The big question (for me, at least) is: why not Backbone.js?
- mambodog 14y ago
  Lack of automatic 2-way data binding?
  - boubiyeah 14y ago
    backbone is just not worth it; May as well use vanilla JS.
jongold 14y ago
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 :)

267 points by EvilTrout 14y ago

someone13 14y ago

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

EvilTrout 14y ago
Fixed, thanks!

tomdale 14y ago

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/ 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 https://twitter.com/tomdale/status/300653212472598528 [3] https://twitter.com/tomdale/status/300653225785311232 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.

deafbybeheading 14y ago
Indeed. A few years ago, I worked in an Adobe Flex on a reporting front-end that had significant client-side complexity and required us to support relatively old browsers. We re-evaluated competing JavaScript solutions periodically, but we never found anything that was worth the gamble of moving off that platform (even though rumors of its death seemed less and less exaggerated every day). These days, I'd move to Ember or Angular in a heartbeat.
saurik 14y ago
My #1 problem with these kinds of applications (which I've complained about before with regards to other attempts at this, such as GitHub) is actually an issue that Discourse clearly still has in spades: it breaks the page cache (not the http cache, but the rendered page cache). The result is that when you hit "back", something you constantly do in a forum while navigating through the content, instead of nearly instantaneously seeing the old content (as it was still in memory, waiting to be moved back into view), it chugs for a second clearing parts of the DOM, then prints a "Loading..." message with a spinner as it painfully rebuilds the DOM of the previous page, and finally I get to see my content, when I only even needed it for a split second to click the next link to go to the next item I had queued. That aside, Discourse actually doesn't handle the scrolling position correctly. It isn't as bad as people like to make out offline web applications to be ("all the content is gone, and I have to start at the top again"), and it isn't even as bad as offline web applications need to be (they could be tracking the actual positions, for example; but this is even more work and is likely to cause some other problem), but even though they seem to have gone out of their way to improve this part of the experience over how most offline web applications work, it still doesn't do a good job of it: the result is that you are constantly being jarred around while attempting to navigate. I just don't think it is accurate to say these things "work just great in Discourse". Specifically, you are never going to be looking directly at a single post: you are always going to, by random chance, be scrolled to a position somewhere partway through a post. You even may purposely be scrolled partway through a long post: as you are reading it, and the scroll position is helping you keep your place. When you navigate forward and then hit back, as part of rebuilding that page based on the URL you were at, it moves you to the next full post boundary. (In practice, it is even worse than this, as it seems to chunk multiple posts together sometimes depending on what kind of activity you are performing.) They also only solved one of the problems for topics and the other problem for threads, so if you are looking at a topic and are scrolled down somewhat, there doesn't seem to be any way to throw someone (or yourself on a different computer) a hyperlink 50 pages (or even one page) deep into the topic list. So, while I appreciate your comment that people get these things wrong and have misconceptions (and I realize that it is probably somewhat your job to be the guy who makes posts like this one whenever it seems marginally appropriate ;P), I fear that you are choosing to lump in everyone who disagrees into the same bucket :(. For the record: I write HTML5 offline applications (thanks to Yehuda, who didn't warn me just how many browser bugs I'd run into while attempting to do so ;P), and I have one deployed right now with tens of millions of users. (As proof, here's my appcache manifest: http://cydia.saurik.com/ui/ios/1.1/cache.manifest http://cydia.saurik.com/ui/ios/1.1/cache.manifest ;P.) Yet, the things that people bring up about these kinds of applications really are problems if you don't address them correctly (which often involves not drinking as much of the Kool-Aid, or going through a ton of extra work to simulate something you normally get faster and for free), and I'm really not seeing how Discourse is that much different than other previous attempts at this. Now, as someone who (again) uses these technologies myself, I definitely agree with your comment about being excited for the cool stuff people will build in 2013, and I know that a lot of these issues are surmountable, and that they will be surmounted over time. However, I must say that I'm concerned, as someone who has been thinking about using Ember.js, that someone from the Ember.js team seems to be claiming that Discourse is a great example to prove that modern web applications don't have these classic problems. I would actually be much happier to read a post about how disappointed you were in the way Discourse was built, and how you feel like if they had used Ember more appropriately they would have gotten a better result, as you actually have solutions for some of these age-old problems that the people who built this specific website ignored ;P.

cleverjake 14y ago

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 14y ago
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 14y ago
  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 14y ago

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.

jweir 14y ago

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

brown9-2 14y ago
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 14y ago
  You might want to have a look at http://egghead.io/ 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.
- slmt 14y ago
  I haven't gone through all the egghead.io tutorials yet, but I suspect transclusion is addressed in one of the screencasts.
- jonny_eh 14y ago
  The learning curve definitely hits a trough at a certain point but you'll get through. It's totally worth it, I'm glad I stuck with it.
methehack 14y ago
Picking on transclusion seems really unfair. It's a well known rough spot in the docs and has been addressed in a bunch of places outside the formal docs that aren't hard to find. Plus, you can do tons with the framework without touching on it at all. To quote it, as the article does, as if its typical of the framework is disingenous. IME, the angular docs are way easier to understand than the ember docs and they're more accurate too. I've tried twice with the ember docs, and yes recently, and both times I gave up in eye-rolling wtf frustration. I'd love to use the framework, but there's only so far I'm willing to travel barefoot. The thing that bothers me most about this whole ember vs angular thing is that there seems like a crypto-subtext here. I'm not sure what exactly is going on but there's definitely an "open source mafia" versus "big corporate google guys" thing happening. I think, maybe, the fear from the open source mafia end is that google is going to cram deep support for angular into chrome -- this is not insane and would prolly make sense technically if not for those pesky standards -- and that ultimately this is going to do other frameworks a disservice. Wild speculation alert, okay, but still some politicizing of the the debate is definitely flying around here. I'd be happier if it were out in the open.

ft_ 14y ago

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 14y ago
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_ 14y ago
  Thanks for the info!

seivan 14y ago

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.

mixonic 14y ago
I'm using Ember-Rails every day, and hundreds of others must be as well. If it's broken for you, please create an issue! I think I'm on master as of two weeks ago and sailing smoothly.
robotmay 14y ago
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.

eksith 14y ago

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.

sams99 14y ago
You get a very basic view with non js, which gives you most of the information but does not allow you to contribute anything to the sites. This is mainly done for search engines.
steveklabnik 14y ago
> 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 http://words.steveklabnik.com/emberjs-and-accessibility
- eksith 14y ago
  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 14y ago
    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- 14y ago

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 14y ago
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 14y ago
  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-ember-app-with-rails-api-part-1.html http://reefpoints.dockyard.com/ember/2013/01/07/building-an-...
  - steveklabnik 14y ago
    The peepcode is well worth the $12.
    - kaliblack 14y ago
      Perfect. That's exactly what I need. Thanks.

atomical 14y ago

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

sams99 14y ago
can you please expand on this? not following

deleted 14y ago

[deleted]

mrgordon 14y ago

"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 14y ago
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/posts/393849 http://www.kickstarter.com/projects/1397300529/railsapp/post... [2]: https://github.com/tokaido https://github.com/tokaido [3]: https://github.com/sproutcore/sproutcore https://github.com/sproutcore/sproutcore
- mrgordon 14y ago
  Merb and Rails did merge, but that doesn't mean any reasonably sized Merb codebases had any hope to migrate. It's a different framework with a different ORM. All those developers that followed Katz early on got burned when he joined Rails core. I do believe Rails.app will be released and Katz has recently given an update (it's dated January 27) but the first dozen comments at http://www.kickstarter.com/projects/1397300529/railsapp/comments http://www.kickstarter.com/projects/1397300529/railsapp/comm... will show that there has been some community concern that they bought into vaporware/Ember.js. Those comments went on from November 15 to January 25 before a Hacker News post solicited a comment. In regards to SproutCore, I was referring to SproutCore 2.0 which became Amber which became Ember.js. Ember.js seems to be coming together nicely, but we are already supporting 4 completely incompatible versions of it. Admittedly we are still at ember-1.0.0-pre.2 and I'm sure the APIs will eventually solidify, but it feels like even new patch versions have been radically incompatible. Definitely excited to see Rails 4, Ember 1.0, etc. for the record. I just have spent a significant amount of time cleaning up the messes of abandoned Merb codebases so I couldn't help but point out that Katz's legacy has been, at best, mixed here.

crazygringo 14y ago

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

stevewilhelm 14y ago

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?

jaequery 14y ago

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

CornishPasty 14y ago
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.

robotmay 14y ago

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.

patrickaljord 14y ago

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=eJZx9c6YL8k#t=1978s http://www.youtube.com/watch?feature=player_detailpage&v...

meric 14y ago

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/23 http://meta.discourse.org/t/welcome-to-meta-discourse-org/1/... 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 http://news.ycombinator.com/item?id=5198934

melvinmt 14y ago

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

mambodog 14y ago
Lack of automatic 2-way data binding?
- boubiyeah 14y ago
  backbone is just not worth it; May as well use vanilla JS.

jongold 14y ago

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 :)