5 ms·

No adding/removing/modifying elements in a list is very simple and fast, even with thousands of elements. Example: https://pastebin.com/Fu39i47z https://pasteb

by olavgg 9y ago

No adding/removing/modifying elements in a list is very simple and fast, even with thousands of elements. Example: https://pastebin.com/Fu39i47z https://pastebin.com/Fu39i47z

csallen 9y ago
jasim isn't complaining about performance, but about the complexity of the code.
- valarauca1 9y ago
  Parent's paste bin is ~40 lines of code (with white space) consisting of 4 functions, with what? 4 loops. If you consider 40LOC complex I don't understand why you work as a dev.
  - jasim 9y ago
    > If you consider 40LOC complex I don't understand why you work as a dev. Goodness, your snark that questions the parent's competence is not only unwarranted, it is based on an incomplete understanding of the value of abstractions in programming. It is not about 40 lines of code, it is about a basic programming model that allows us to understand and create user interfaces irrespective of how complex or large it is. It lets you compose your UI based on a tree of state and pure functions. If you don't have this abstraction, you do not have a coherent programming model to build UIs.
    - drdaeman 9y ago
      Actually, I wonder if there's something out there that has all the declarative state-to-DOM manipulation goodness, but does this at build time. React is a runtime that works on the client, and its compile-time stuff is just syntax sugar (JSX) and some minor optimizations. As I understand, this runtime is the complexity that some complain about. At least I perceive this as a downside. If there's something that can, given a component definition, generate those sets of add/update/remove functions and appropriate calls on state updates (preferably, as human-readable as possible) - I think that would be interesting to see and compare. (I hope no one normally dynamically mutates their components at runtime?)
      - jasim 9y ago
        https://svelte.technology/ https://svelte.technology/ is what you're looking for. I haven't ever used it because I find React quite adequate. I share your concern about the complex runtime layer that React introduces, and it is getting even more complex with the introduction of Fiber. However, the test of an abstraction is whether it leaks undesirably, and whether it lets you escape to the lower layers when you need to. React scores well on both counts. So while the implementation might be complex and will get even more elaborate over time, the abstraction is as water-tight as I can hope. In that case complex implementations with better performance might even be a good thing. Also, I strolled through the React codebase in its early days and found it eminently understandable. So if it ever comes to it, I'm confident I can contribute a patch for the things I need with enough time and effort.
drdaeman 9y ago
The good part about React is that given a `messages` data structure and a `render` function, it implements `addMessage`/`addMessageBefore`/`updateMessage`/`removeMessage` on its own. Writing once and not multiple variants of the same is good. Another good thing is that that there are a lot of components someone already published, that are ready to use (immediately, or after a few small fixes/PRs). The bad part is that React has a lot of code on its own, and somewhat strongly suggest use of even more. It's orders of magnitude more than that your `{add,update,remove}Message` snippet has. While React tries its best to hide all that complexity, it's still there. Designing, writing, reading, debugging and rewriting (if necessary) those few functions is all trivial (but somewhat routine) - not so much with React.
- platz 9y ago
  all the add/remove list stuff can be implemented by a simple templating library (handlebars/mustache) which doesnt mess up the whole client side architecture
  - drdaeman 9y ago
    Oh, no, I'm sure that's incorrect. Templating libraries can't update documents, they can only overwrite them completely. This either loses state (entered-but-unsaved text, cursor positions, <detail> collapse status, etc.), or requires a lot of watchers and extra state information. Those DOM updates is the whole point of React. There are other libraries that work in a similar fashion, but React has more traction thus reusable components and recipes available...
    - platz 9y ago
      no, the point of the template engine is not to push all the logic into the templates. as you say you still handle the state yourself. the template render just skips the messy output building step, which for many cases is all you need
      - drdaeman 9y ago

by olavgg 9y ago

No adding/removing/modifying elements in a list is very simple and fast, even with thousands of elements. Example: https://pastebin.com/Fu39i47z https://pastebin.com/Fu39i47z

csallen 9y ago

jasim isn't complaining about performance, but about the complexity of the code.

valarauca1 9y ago
Parent's paste bin is ~40 lines of code (with white space) consisting of 4 functions, with what? 4 loops. If you consider 40LOC complex I don't understand why you work as a dev.
- jasim 9y ago
  > If you consider 40LOC complex I don't understand why you work as a dev. Goodness, your snark that questions the parent's competence is not only unwarranted, it is based on an incomplete understanding of the value of abstractions in programming. It is not about 40 lines of code, it is about a basic programming model that allows us to understand and create user interfaces irrespective of how complex or large it is. It lets you compose your UI based on a tree of state and pure functions. If you don't have this abstraction, you do not have a coherent programming model to build UIs.
  - drdaeman 9y ago
    Actually, I wonder if there's something out there that has all the declarative state-to-DOM manipulation goodness, but does this at build time. React is a runtime that works on the client, and its compile-time stuff is just syntax sugar (JSX) and some minor optimizations. As I understand, this runtime is the complexity that some complain about. At least I perceive this as a downside. If there's something that can, given a component definition, generate those sets of add/update/remove functions and appropriate calls on state updates (preferably, as human-readable as possible) - I think that would be interesting to see and compare. (I hope no one normally dynamically mutates their components at runtime?)
    - jasim 9y ago
      https://svelte.technology/ https://svelte.technology/ is what you're looking for. I haven't ever used it because I find React quite adequate. I share your concern about the complex runtime layer that React introduces, and it is getting even more complex with the introduction of Fiber. However, the test of an abstraction is whether it leaks undesirably, and whether it lets you escape to the lower layers when you need to. React scores well on both counts. So while the implementation might be complex and will get even more elaborate over time, the abstraction is as water-tight as I can hope. In that case complex implementations with better performance might even be a good thing. Also, I strolled through the React codebase in its early days and found it eminently understandable. So if it ever comes to it, I'm confident I can contribute a patch for the things I need with enough time and effort.

drdaeman 9y ago

The good part about React is that given a `messages` data structure and a `render` function, it implements `addMessage`/`addMessageBefore`/`updateMessage`/`removeMessage` on its own. Writing once and not multiple variants of the same is good. Another good thing is that that there are a lot of components someone already published, that are ready to use (immediately, or after a few small fixes/PRs). The bad part is that React has a lot of code on its own, and somewhat strongly suggest use of even more. It's orders of magnitude more than that your `{add,update,remove}Message` snippet has. While React tries its best to hide all that complexity, it's still there. Designing, writing, reading, debugging and rewriting (if necessary) those few functions is all trivial (but somewhat routine) - not so much with React.

platz 9y ago
all the add/remove list stuff can be implemented by a simple templating library (handlebars/mustache) which doesnt mess up the whole client side architecture
- drdaeman 9y ago
  Oh, no, I'm sure that's incorrect. Templating libraries can't update documents, they can only overwrite them completely. This either loses state (entered-but-unsaved text, cursor positions, <detail> collapse status, etc.), or requires a lot of watchers and extra state information. Those DOM updates is the whole point of React. There are other libraries that work in a similar fashion, but React has more traction thus reusable components and recipes available...
  - platz 9y ago
    no, the point of the template engine is not to push all the logic into the templates. as you say you still handle the state yourself. the template render just skips the messy output building step, which for many cases is all you need
    - drdaeman 9y ago