5 ms·

The thing I enjoy about frameworks like React is the declarative nature of the UIs. I'd love to not be able to use them and to create complex UIs in pure JavaS

The thing I enjoy about frameworks like React is the declarative nature of the UIs. I'd love to not be able to use them and to create complex UIs in pure JavaScript but it always ends up being painful where you spend more time optimising the rendering than doing any work. In simple apps I will write UI in a functional matter in pure JavaScript, regardless of the performance implications. But bigger DOM means worse performance with this method. When will we get to the point where we can tell the browser what we want the DOM to look like and then the browser does the diffing like a framework would?

kgbcia 4y ago
i agree it's up to the browsers chromium , Safari , and Firefox to do the diff. But we might need a new meta tag or change to the Fetch API to tell them this html page should only update the elements that are different. Remember <meta http-equiv="refresh" content="5"> . It was discouraged because the back button broke. If you're developing a single page react app, I don't think you care about the back button.
- creakingstairs 4y ago
  > If you're developing a single page react app, I don't think you care about the back button. You should though. One easy way is to use react-router. e.g. going to /profile renders the Profile component. Then navigating to /dashboard renders the Dashboard component. Pressing the back button will take you to /profile. Another pet peeve of mine is people using internal react state when they should just use path or query params to make it transparent and easily sharable.
- alserio 4y ago
  The primitives of fine grained reactive programming seem to me more amenable to be implemented by the browser than react-style whole world diffing
- nkrisc 4y ago
  > If you're developing a single page react app, I don't think you care about the back button. Your users likely do, so you should too.
mattgreenrocks 4y ago
Echoes of Alan Kay's recent comment on how software devs are way too concerned with the how the computer works to the detriment of what the software is supposed to do.
- emteycz 4y ago
  The battle is fought over performance and size, I think that's exactly what the user wants.
  - vips7L 4y ago
    I don’t think the typical user cares about size.
    - oblib 4y ago
      I agree. In over 20 years I've never had a single user ask or complain about the size of the app. They have let me know when there was something not working right though.
      - 1marc 4y ago
        People definitely notice speed and performance. They won’t complain about it generally, sure… but there’s plenty of data and case studies on the fact that users care https://nitropack.io/blog/post/web-performance-matters-case-studies https://nitropack.io/blog/post/web-performance-matters-case-...
        ramesh31 4y ago
        >People definitely notice speed and performance. There's sort of a "Maslow's Hierarchy of User Needs" that exists in software though. So long as the user can do something, and their immediate needs are met, performance concerns are just a small annoyance. And generally they will continue to ask for more features rather than performance improvements as long as the app remains usable.
      - 4y ago
anonymoushn 4y ago
it sounds sort of wild to expect there to be diffing! why do you have to generate a whole copy of the stuff instead of just telling the browser what changes to make? bonus: the existing apis instead of one that don't exist yet.
- Bilal_io 4y ago
  Diffing seems necessary when your UI gets complicated to the level that a small change requires a full page re-render. However, I don't think this is necessary for at least 95% of the websites on the internet.
- dymk 4y ago
  Diffing is exactly what you need to do (barring newer methods like svelte) to figure out what to tell the browser to change. The vdom tree is much faster to manipulate than DOM nodes.
  - recursive 4y ago
    But you can't see those changes until the actual DOM changes as well. It's only because of react's insistence that mutation is evil that this became a problem. You could just directly update the thing you wanted to and just skip the whole diff thing.
    - dymk 4y ago
      No, the reason React has a VDOM is because the DOM is slow to update, compared to manipulating javascript objects. It's worthwhile to calculate the list of minimum updates ahead of time rather than using the DOM as the source of truth. Not sure where you think mutation comes into play here, that's an orthogonal concern—you can have an API that mutates some internal representation of a VDOM, and it's still faster than manipulating the DOM directly.
      - recursive 4y ago
        In order to achieve immutability, large chunks of state have to be cloned whenever a single value changes. This sometimes causes a whole new DOM node to be created during reconciliation. React encourages you not to think about it too much. But some nodes can't be replaced. Like canvas or anything contentEditable. It's not orthogonal. It's a direct consequence of the design philosophy.
ricardobeat 4y ago
There’s absolutely no way you’ll have worse performance with this vs React. The app is modifying the target elements directly, not recreating the whole page with innerHTML. React will do the same amount of work at a minimum, and that’s after rebuilding the whole tree and diffing it. The main bottleneck here are the synchronous localStorage calls happening in the render path, they could be moved to a separate timer.
- toomim 4y ago
  One way React can be faster than hand-written code is by batching all dom manipulation into animation frames.
  - ricardobeat 4y ago
    The rendering code here is already batched since everything happens within a single render() call. And unless you’re using react fiber, its rendering is also synchronous.
  - sarchertech 4y ago
    Handwritten JS could also batch DOM manipulation (without the need for virtual dom comparison).
    - SemanticStrengh 4y ago
      https://github.com/wilsonpage/fastdom https://github.com/wilsonpage/fastdom
      - 1marc 4y ago
        Ooo fastdom looks great! Thanks for the link.
        SemanticStrengh 4y ago
        https://www.youtube.com/watch?v=VKMw2it8dQY https://www.youtube.com/watch?v=VKMw2it8dQY
recursive 4y ago
Cases where "UI should be a function of state" seem like a small sliver of all use cases. Probably not worth the complexity for implementing directly in the browser. And there are plenty of conditions that just prohibit the pattern entirely as far as I can tell. Things where referential stability matters, like you have a contentEditable or allow arbitrary edits on a canvas.
- deergomoo 4y ago
  Personally I would argue that UI should always be a function of state. When it isn’t, you open yourself up to all sorts of inconsistencies and difficult edge cases. Of course, it’s not always that easy; having two sources for said UI (the HTML document itself and the JavaScript within it) certainly complicates matters.
  - eyelidlessness 4y ago
    For what it’s worth, even using “vanilla” JS it’s generally much easier than it’s made out to be. It requires design discipline and knowing ahead of time what discipline to apply. But it’s pretty simple once you know it: - the UI isn’t a source of truth, it’s a computed interface to it - changes/interactions in the UI should update the source of truth, not other parts of the UI - the source of truth is fully responsible for managing and notifying dependencies of relevant changes Or much shorter: state and presentation are separate concerns. Once you have that, you can focus on the actual problems you’re trying to solve rather than the ones created by crossing underlying technology boundaries.
- eyelidlessness 4y ago
  > Cases where "UI should be a function of state" seem like a small sliver of all use cases. Maybe not “should”, but it’s an incredibly helpful mental model, and I can think of very few cases it can’t model correctly. It’s so helpful a model that it’s gained traction in Rust, Swift, Kotlin, Dart, Go. It’s the ~only model in Clojure and and literally the foundation of Elm. None of these cases, AFAIK, apply the model literally when they interface with inherently imperative APIs. They provide APIs expressing the model, and manage the imperative behavior on your behalf. This is ultimately how all functions in meaningful programming work. At the end of the day, allocating memory or displaying output is a side effect. This is also how you can have custom renderers like those used in ink, three-solid, even React Native. The code is modeled as a declarative function of state, implemented as a set of imperative behaviors corresponding to state and dependency changes. I’ve worked on contentEditable solutions in the past, probably more than most people who didn’t ultimately produce a library from the work (I went mad, literally angry at the complexity of making it a good UX, and gave up). I hope I never have that task again, but if I do… you can bet your ass I’d use a function of state model. It’s the only way I could reason about the problem without going mad.

kgbcia 4y ago

i agree it's up to the browsers chromium , Safari , and Firefox to do the diff. But we might need a new meta tag or change to the Fetch API to tell them this html page should only update the elements that are different. Remember <meta http-equiv="refresh" content="5"> . It was discouraged because the back button broke. If you're developing a single page react app, I don't think you care about the back button.

creakingstairs 4y ago
> If you're developing a single page react app, I don't think you care about the back button. You should though. One easy way is to use react-router. e.g. going to /profile renders the Profile component. Then navigating to /dashboard renders the Dashboard component. Pressing the back button will take you to /profile. Another pet peeve of mine is people using internal react state when they should just use path or query params to make it transparent and easily sharable.
alserio 4y ago
The primitives of fine grained reactive programming seem to me more amenable to be implemented by the browser than react-style whole world diffing
nkrisc 4y ago
> If you're developing a single page react app, I don't think you care about the back button. Your users likely do, so you should too.

mattgreenrocks 4y ago

Echoes of Alan Kay's recent comment on how software devs are way too concerned with the how the computer works to the detriment of what the software is supposed to do.

emteycz 4y ago
The battle is fought over performance and size, I think that's exactly what the user wants.
- vips7L 4y ago
  I don’t think the typical user cares about size.
  - oblib 4y ago
    I agree. In over 20 years I've never had a single user ask or complain about the size of the app. They have let me know when there was something not working right though.
    - 1marc 4y ago
      People definitely notice speed and performance. They won’t complain about it generally, sure… but there’s plenty of data and case studies on the fact that users care https://nitropack.io/blog/post/web-performance-matters-case-studies https://nitropack.io/blog/post/web-performance-matters-case-...
      - ramesh31 4y ago
        >People definitely notice speed and performance. There's sort of a "Maslow's Hierarchy of User Needs" that exists in software though. So long as the user can do something, and their immediate needs are met, performance concerns are just a small annoyance. And generally they will continue to ask for more features rather than performance improvements as long as the app remains usable.
    - 4y ago

anonymoushn 4y ago

it sounds sort of wild to expect there to be diffing! why do you have to generate a whole copy of the stuff instead of just telling the browser what changes to make? bonus: the existing apis instead of one that don't exist yet.

Bilal_io 4y ago
Diffing seems necessary when your UI gets complicated to the level that a small change requires a full page re-render. However, I don't think this is necessary for at least 95% of the websites on the internet.
dymk 4y ago
Diffing is exactly what you need to do (barring newer methods like svelte) to figure out what to tell the browser to change. The vdom tree is much faster to manipulate than DOM nodes.
- recursive 4y ago
  But you can't see those changes until the actual DOM changes as well. It's only because of react's insistence that mutation is evil that this became a problem. You could just directly update the thing you wanted to and just skip the whole diff thing.
  - dymk 4y ago
    No, the reason React has a VDOM is because the DOM is slow to update, compared to manipulating javascript objects. It's worthwhile to calculate the list of minimum updates ahead of time rather than using the DOM as the source of truth. Not sure where you think mutation comes into play here, that's an orthogonal concern—you can have an API that mutates some internal representation of a VDOM, and it's still faster than manipulating the DOM directly.
    - recursive 4y ago
      In order to achieve immutability, large chunks of state have to be cloned whenever a single value changes. This sometimes causes a whole new DOM node to be created during reconciliation. React encourages you not to think about it too much. But some nodes can't be replaced. Like canvas or anything contentEditable. It's not orthogonal. It's a direct consequence of the design philosophy.

ricardobeat 4y ago

There’s absolutely no way you’ll have worse performance with this vs React. The app is modifying the target elements directly, not recreating the whole page with innerHTML. React will do the same amount of work at a minimum, and that’s after rebuilding the whole tree and diffing it. The main bottleneck here are the synchronous localStorage calls happening in the render path, they could be moved to a separate timer.

toomim 4y ago
One way React can be faster than hand-written code is by batching all dom manipulation into animation frames.
- ricardobeat 4y ago
  The rendering code here is already batched since everything happens within a single render() call. And unless you’re using react fiber, its rendering is also synchronous.
- sarchertech 4y ago
  Handwritten JS could also batch DOM manipulation (without the need for virtual dom comparison).
  - SemanticStrengh 4y ago
    https://github.com/wilsonpage/fastdom https://github.com/wilsonpage/fastdom
    - 1marc 4y ago
      Ooo fastdom looks great! Thanks for the link.
      - SemanticStrengh 4y ago
        https://www.youtube.com/watch?v=VKMw2it8dQY https://www.youtube.com/watch?v=VKMw2it8dQY

recursive 4y ago

Cases where "UI should be a function of state" seem like a small sliver of all use cases. Probably not worth the complexity for implementing directly in the browser. And there are plenty of conditions that just prohibit the pattern entirely as far as I can tell. Things where referential stability matters, like you have a contentEditable or allow arbitrary edits on a canvas.

deergomoo 4y ago
Personally I would argue that UI should always be a function of state. When it isn’t, you open yourself up to all sorts of inconsistencies and difficult edge cases. Of course, it’s not always that easy; having two sources for said UI (the HTML document itself and the JavaScript within it) certainly complicates matters.
- eyelidlessness 4y ago
  For what it’s worth, even using “vanilla” JS it’s generally much easier than it’s made out to be. It requires design discipline and knowing ahead of time what discipline to apply. But it’s pretty simple once you know it: - the UI isn’t a source of truth, it’s a computed interface to it - changes/interactions in the UI should update the source of truth, not other parts of the UI - the source of truth is fully responsible for managing and notifying dependencies of relevant changes Or much shorter: state and presentation are separate concerns. Once you have that, you can focus on the actual problems you’re trying to solve rather than the ones created by crossing underlying technology boundaries.
eyelidlessness 4y ago
> Cases where "UI should be a function of state" seem like a small sliver of all use cases. Maybe not “should”, but it’s an incredibly helpful mental model, and I can think of very few cases it can’t model correctly. It’s so helpful a model that it’s gained traction in Rust, Swift, Kotlin, Dart, Go. It’s the ~only model in Clojure and and literally the foundation of Elm. None of these cases, AFAIK, apply the model literally when they interface with inherently imperative APIs. They provide APIs expressing the model, and manage the imperative behavior on your behalf. This is ultimately how all functions in meaningful programming work. At the end of the day, allocating memory or displaying output is a side effect. This is also how you can have custom renderers like those used in ink, three-solid, even React Native. The code is modeled as a declarative function of state, implemented as a set of imperative behaviors corresponding to state and dependency changes. I’ve worked on contentEditable solutions in the past, probably more than most people who didn’t ultimately produce a library from the work (I went mad, literally angry at the complexity of making it a good UX, and gave up). I hope I never have that task again, but if I do… you can bet your ass I’d use a function of state model. It’s the only way I could reason about the problem without going mad.