5 ms·

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

• 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.
  • deleted 14y ago
    [deleted]
  • codinghorror 14y ago
    I can't repro this. (The following are all screenshots taken at exactly the point described.) I am scrolled down on the main page of http://meta.discourse.org http://meta.discourse.org viewing topics. http://i.imgur.com/dr0V0dn.png http://i.imgur.com/dr0V0dn.png 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.) http://i.imgur.com/OMcKAW5.png http://i.imgur.com/OMcKAW5.png I then click the back button, and go... http://i.imgur.com/5e4DpK4.png http://i.imgur.com/5e4DpK4.png 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.)
    • saurik 14y ago
      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).
• hcarvalhoalves 14y ago
  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 14y ago
    >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 14y ago
      > 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).
• deleted 14y ago
  [deleted]