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].
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.
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 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.
>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.
> 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).
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.
If you step back and look at these apps they basically are JS VMs with HTTP capabilities with a very powerful visual templating engine driven by HTML/CSS.
I'm just talking about rendering a page based on what you specify in HTML/CSS, not the component model you might want to add behind.
I'm pretty sure there's no technology more optimized for displaying content-rich visual information than HTML/CSS and the browser's rendering engines.
It's that combined with the fact that this has been the lingua-france for every web-designer wishing to express himself for the past decade that makes it a winning combination...
What are those powerful GUI engines you talk of? I'm generally interested because most "modern" GUI frameworks seem to be huge, bloated and utterly messy.
Conceptually, XML/QML/XAML and databinding, as used in QTQuick or WPF on the desktop, are not very different from mixing HTML and JavaScript frameworks such as angular.js on the web.
I don't like the approach, be it on the desktop or with web applications. Are there alternatives?
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.
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 ;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.
I click on the topic "Development on Windows". (My read position was already at the bottom of the topic, so that's where I go. There are no new replies to read.)
back to exactly the position, the very same position by pixel, I was at.
Maybe I don't understand what you are talking about, because I can't reproduce it? Can you share some screenshots?
It is true that when you deep-link into a topic you've already read, with new replies, we take you to the top of the post you had a last read position at. But that seems unavoidable and correct to me. (You could argue we should start you at the post below the last one you read, I guess.)
As I stated, they (edit: you? I was replying from my iPhone before, and skipped the username) solved half the problem (scroll pixel offset) for the topic thread list, and half the problem (inability to deep-link for any of a number of reasons) for thread post lists. Before even having to look at your screenshots, I could tell you are measuring the topic thread lists, showing that you can re-arrive at the same pixel position viewing a list of threads. However, if you try to do the same thing for posts (where this is even noticeable: as I described, a post might be long), it fails. (To describe this differently: you seem to have ignored the part about being scrolled halfway through a post, because the list you were looking at didn't even have posts... ;P.)
(added:)
> It is true that when you deep-link into a topic you've already read, with new replies, we take you to the top of the post you had a last read position at. But that seems unavoidable and correct to me. (You could argue we should start you at the post below the last one you read, I guess.)
This is related, but not the issue: if you are looking at the middle of some post, click a link in that post or click a link surrounding that post, and then hit back, you are brought back to a position at the top of that post, as it rebuilds your location based on the URL you were coming from (which, again, is sometimes even worse than that, as sometimes it seems that certain sinews of multiple posts forming a sub-conversation seem to be ignored for constructing the URL, so you are brought back to the top of the entire thing).
When I hit back, I get the first page's loading symbol again.
Here's another weird thing:
Sometimes, when I click from the list of posts page through to a post, scroll down, and then hit back, it takes me to the top of the post instead of back to the list of posts. This happens only sometimes, not always.
Also, it looks like you are tracking scroll position by chopping up the page into numbered sections which are tracked in the url. Going back and forth resets the scroll position to the top of the tracked section. This works mostly fine, but is off sometimes by a line or two.
Edited to add:
In an earlier post[1], Robin argues that using client-side frameworks like Ember increases speed because you can leverage CDNs. But, I think our examples suggest that there are still some speed issues in the client-side rendering, which I think is DHH's point.
Even if total times with Ember (request to server and final render) might be less than something like pure Rails, the perceived speed for the user might be lower.
Robin gives one anecdote of some people in Prague finding his Ember site faster than others. saurik and I have provided couple more anecdotes :-)
But, it might be good to collect some proper data using something like Torbit.
> I can repro it. The lag is only of a few milliseconds, but enough to capture a screenshot, so it is jarring for sure.
I would say this is at least a few hundred milliseconds; if nothing else, I dare you to succeed in taking a screenshot of something that only lasts for milliseconds ;P. (I say this only because someone else might get the wrong impression about how intrusive it ends up being.)
> Also, it looks like you are tracking scroll position by chopping up the page into numbered sections which are tracked in the url. Going back and forth resets the scroll position to the top of the tracked section. This works mostly fine, but is off sometimes by a line or two.
This is the actually specific issue I was complaining about with the scroll position (and which I think was what was trying to be reproduced); its awesome that you found another one, though ;P. The longer the posts (and even just a post with a YouTube video in it is half my screen height) the more off the scroll position becomes. I often see posts on the forums I use that are a couple screens long: clicking a link from them and then hitting back with Discourse resets you to the top of the post, as the "numbered sections" are the index of the post you are looking at (with that irritating caveat that I've found a bunch of contexts where there are multiple post-like thing that somehow "don't count" for the URL).
Try viewing a topic, not the topic list, scroll down a ways into the discussion, and click a link that's posted in the discussion. Then click back. I think that's what the original post is complaining about. I was able to reproduce it on chrome.
That page cache issue is a real one; Do you think this issue can be worked arround or mitigated? Or is it a tradeoff of using full client side navigation (tradeoff because ALL other navigation kinds are faster)?
> 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...
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/... 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 ;)"
"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.
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?
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.
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.
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/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.
FUD is a mid-nineties term about certain MS practices. Best left to the mid-nineties and/or 4chan types. He made a point, make a counterpoint. No reason to call what he wrote FUD or trolling or whatever. Especially when he writes that we was personally affected by the Merb thing.
>First of all, I'm not familiar with Merb but didn't it merge with Rails?
How is that different from the Merb project that he relied upon being abandoned? That he was given an "upgrade path" if he took the time to rewrite his apps to use the new post-merge Rails?
>Regarding Rails.app, how is it languishing? Yehuda has given status updates[1] and code is on Github right now[2].
- Status updates after someone brought the whole issue to HN attention?
- With things promised to backers still not sent whole months after the promised dates?
- And with taking the money to work on the project and then devoting his time in another venture?
Maybe the project is not "languishing", but it sure is late. And "did something else in the meantime" is not a proper excuse to paying backers.
>SproutCore continues to be developed to this day
By others. But the subject matter on this subthread was Katz as a contributor, and he has migrated away long 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.
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.
I find that it is really hard to put myself in the shoes on someone who relies on accessibility tools to brows with. I do all kinds of things for accessibility, but there is no good equivalent of unit testing or continuous integration for accessibility that I know of. Maybe that’s a start-up waiting to be created. :)
Any good books on the subject? I already use ARIA attributes, which I didn’t know about at all until very recently, and there could be more people like I and the Discourse guys would benefit from reading up on.
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?
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.
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?
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.
This has definitely changed. In the pre-1.0 phase, Ember was supposed to move quickly, to iterate and figure out what the right abstractions were. Since the pre.4 release and the PeepCode (https://peepcode.com/products/emberjs), the core team has committed to keeping the APIs stable.
From this point forward, master is committed to having all the examples in the PeepCode working until 1.0. It's been a long and wild ride mck, but the turbulence has stepped down a notch for sure.
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?
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.
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)
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 http://www.youtube.com/watch?feature=player_detailpage&v...
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.
>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 thought that was weird too:
>Angular, for example, is sponsored by Google, and while I think the project would continue even if they abandoned it, it is important to me that the Ember community didn’t spring out of a corporate sponsorship.
So, Chromium, GWT, Closure Compiler, Android, the now open-sourced Wave, and the fact that Google runs completely on FOSS isn't enough to reassure him on Angular? I don't anything could.
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.
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.
I simply abstracted my self from trying to understand that part and I've been living happily. Although sometimes I feel the need to re-read it, feel frustration and read something else.
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?
"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.
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 ;)
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.
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 :)
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.
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.
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.
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.