4 ms·

I've read a few of these articles from Cake now and I like how it looks but I find using CTRL+F doesn't work correctly. On this article it doesn't seem to pick

I've read a few of these articles from Cake now and I like how it looks but I find using CTRL+F doesn't work correctly. On this article it doesn't seem to pick up anything past the second post unless you go to that post, click on it, and then type in your search.

rgrove 8y ago
Hey, I'm the guy who built that. Sorry about the Ctrl+F troubles. That's happening because we don't actually render all the posts in the conversation; to improve performance, we only render visible posts and a few posts above and below the visible region of the page. Unfortunately browsers don't currently offer any good way for us to make Ctrl+F work for not-yet-rendered posts in this scenario, so this is a tradeoff between better performance and worse find-on-page functionality. I'll give some thought to how to improve this.
- js2 8y ago
  If I disable JavaScript everything is apparently rendered server-side and is indistinguishable from the page loaded with JavaScript enabled, except that ctrl-f works as expected. What's the benefit of progressive rendering via JavaScript here?
  - rgrove 8y ago
    With JavaScript disabled, you'll get a server-rendered page that renders up to 25 posts per page and relies on traditional prev/next pagination. When you scroll to the bottom of the page you'll have to click "Next" to see the next page of posts. With JavaScript enabled, you'll get a hybrid or client-rendered page that only renders the posts that are visible or likely to be visible soon. More posts will be loaded and rendered seamlessly as you scroll until you reach the end of the conversation. The benefit of the JS approach is that we can load and render only the stuff you're likely to see, which keeps data usage down and performance up. This is especially nice on mobile devices and slow connections. We think the infinite pagination is also a nicer experience than manual pagination. But we also want things to work when JS isn't available, primarily because that improves SEO. It's a nice bonus that the tiny percentage of people who prefer to browse with JS disabled can still read Cake.
    - js2 8y ago
      Since this conversation has 19 posts, I didn't notice the pagination. There's less than 20k of actual text with all 19 posts though (which is somewhat sad since the full page source grabbed via curl is nearly 300k). If this 19 post conversation is typical, how much are you saving by using client-side rendering? As well, how many conversations are more than 25 posts? Looking at your front page I only see one and it's just 26 posts (https://www.cake.co/conversations/x97rrxl/why-can-t-apple-make-great-laptops-anymore https://www.cake.co/conversations/x97rrxl/why-can-t-apple-ma...). Pulling it up, there's just not that much text there across all 26 parts (less than 30k of actual text). I don't mean to be grumpy-old-man here, but it seems like you've added a bunch of complexity and broken ctrl-f for questionable gains.
      - rgrove 8y ago
        I know it's not easy to see the justification when looking at the front page, especially since Cake is still pretty young, but we designed Cake to scale to conversations with thousands of posts in order to allow for the kinds of long-lived conversations that continue to attract a trickle of new posts for months or even years. Cake also uses client-side routing when JS is enabled. While the initial pageview might be on the large side since it contains all the data necessary to render the entire page (albeit gzipped for most clients, so typically much smaller than the uncompressed sizes you shared), subsequent pageviews will load a much smaller amount of data. We also use a few heuristics to avoid serving a server-rendered page if we know the client can render it more efficiently, which can further reduce the size of the initial pageview (pretty significantly actually). So you're pretty much measuring our worst case scenario. :)
        js2 8y ago
        Well, fair enough. I wish you luck getting to those thousand post conversations. Aesthetically the site design is pleasing and I find it easy to read. And I hope you can find a solution to ctrl-f. :-)
        rgrove 8y ago

rgrove 8y ago

Hey, I'm the guy who built that. Sorry about the Ctrl+F troubles. That's happening because we don't actually render all the posts in the conversation; to improve performance, we only render visible posts and a few posts above and below the visible region of the page. Unfortunately browsers don't currently offer any good way for us to make Ctrl+F work for not-yet-rendered posts in this scenario, so this is a tradeoff between better performance and worse find-on-page functionality. I'll give some thought to how to improve this.

js2 8y ago
If I disable JavaScript everything is apparently rendered server-side and is indistinguishable from the page loaded with JavaScript enabled, except that ctrl-f works as expected. What's the benefit of progressive rendering via JavaScript here?
- rgrove 8y ago
  With JavaScript disabled, you'll get a server-rendered page that renders up to 25 posts per page and relies on traditional prev/next pagination. When you scroll to the bottom of the page you'll have to click "Next" to see the next page of posts. With JavaScript enabled, you'll get a hybrid or client-rendered page that only renders the posts that are visible or likely to be visible soon. More posts will be loaded and rendered seamlessly as you scroll until you reach the end of the conversation. The benefit of the JS approach is that we can load and render only the stuff you're likely to see, which keeps data usage down and performance up. This is especially nice on mobile devices and slow connections. We think the infinite pagination is also a nicer experience than manual pagination. But we also want things to work when JS isn't available, primarily because that improves SEO. It's a nice bonus that the tiny percentage of people who prefer to browse with JS disabled can still read Cake.
  - js2 8y ago
    Since this conversation has 19 posts, I didn't notice the pagination. There's less than 20k of actual text with all 19 posts though (which is somewhat sad since the full page source grabbed via curl is nearly 300k). If this 19 post conversation is typical, how much are you saving by using client-side rendering? As well, how many conversations are more than 25 posts? Looking at your front page I only see one and it's just 26 posts (https://www.cake.co/conversations/x97rrxl/why-can-t-apple-make-great-laptops-anymore https://www.cake.co/conversations/x97rrxl/why-can-t-apple-ma...). Pulling it up, there's just not that much text there across all 26 parts (less than 30k of actual text). I don't mean to be grumpy-old-man here, but it seems like you've added a bunch of complexity and broken ctrl-f for questionable gains.
    - rgrove 8y ago
      I know it's not easy to see the justification when looking at the front page, especially since Cake is still pretty young, but we designed Cake to scale to conversations with thousands of posts in order to allow for the kinds of long-lived conversations that continue to attract a trickle of new posts for months or even years. Cake also uses client-side routing when JS is enabled. While the initial pageview might be on the large side since it contains all the data necessary to render the entire page (albeit gzipped for most clients, so typically much smaller than the uncompressed sizes you shared), subsequent pageviews will load a much smaller amount of data. We also use a few heuristics to avoid serving a server-rendered page if we know the client can render it more efficiently, which can further reduce the size of the initial pageview (pretty significantly actually). So you're pretty much measuring our worst case scenario. :)
      - js2 8y ago
        Well, fair enough. I wish you luck getting to those thousand post conversations. Aesthetically the site design is pleasing and I find it easy to read. And I hope you can find a solution to ctrl-f. :-)
        rgrove 8y ago