1. 6
  1. 3

    […] until the users want to use the table with 1000 rows. […] when 3000 rows came up it was game over. Too many bindings for all rows, pure HTML file has about 3 MB […] JavaScript Client-Side application would be a much better choice.

    My experience with large tables of data with client side JS frameworks is the exact same as the description of LiveView. You cant bind or have interactivity without it getting out of hand. Do folks have good strategies for that? My go-to is to avoid interfaces which might need that.

    Sorta funny because plain old html has no problem with that style of data.

    1. 3

      Usually the strategy is to only put content into the visible subset of rows, plus some buffer, and then drop rows as they scroll off screen. It’s a pain to do though and you need to fake scrollbars and whatnot. It’s something you do out of necessity, not choice.

      1. 1

        This suggests that the web frontend library world might enjoy some sort of r1k challenge/yardstick: can your framework sort and redisplay one thousand table rows in under 100ms?

      2. 1

        Also economic choice. When you use the same technology for backend and frontend and all developers which you have can work with it you can have better delivery and you don’t have to pay for contractors or external companies to fix simple form(for example). And you don’t need a frontend developer which can not fix backend stuff

        In theory, the optimal pragmatic way to do this, ignoring personal language preference, should be to use JavaScript on both sides. That was, after all, one of the big selling points of Node.js. But whenever I’ve contemplated rewriting my current Phoenix-based product in JS for the sake of making it more approachable to hypothetical new hires, I’ve failed to find a full-stack JS equivalent of Phoenix – that is, designed around server-side rendering with minimal required client-side JS, having out-of-the-box support for web fundamentals like classic form submission with CSRF protection, and a good out-of-the-box solution for real-time applications like Phoenix’s channels. And Phoenix is getting even better as a full-stack framework, with its new out-of-the-box auth and email support. I’m pretty surprised that the Node.js community hasn’t yet developed a widely used Rails or Phoenix equivalent.