4 ms·

Depending on the complexity of your computations and state, what you just described can basically become unusable. For example, an app I work on implements a sp

Depending on the complexity of your computations and state, what you just described can basically become unusable. For example, an app I work on implements a spec which: - Models state as an arbitrary DAG - With arbitrarily deep dependency chains - Which may trigger dependent nodes based on only subsets of their state - Based on computations of arbitrary XPath expressions, sometimes containing non-native extensions; these can be expensive whether implemented as a hybrid wrapper around native XPath or fully in userland - Which in turn may trigger recomputation of their own dependent nodes A naive implementation of this according to the algorithm you described will cause real world usage to block sometimes for several seconds until the app becomes responsive again. Being able to have greater control over when to commit state and when to render intermediate state are crucial to usability for this app. Being able to defer the entire computation for state without a path to an associated view is even better. Being able to batch state -> render updates based on priority even better still. All of this can be accomplished with React’s APIs, but it certainly wouldn’t be the default behavior. And it’s all from a real world use case where SolidJS—which has a similar DX to React but significantly better performance, and which I’ve been prototyping for gradual adoption—also needs more optimization than its dependency tracking alone can achieve. Even trivial demo apps with well designed pre-hydration state (note: already optimized beyond the default) and otherwise find performance at runtime can suffer significant lag between LCP and TTI by running far too much code for stuff that’s nowhere near needed for immediate interaction. Granted in most cases this tradeoff is reasonably acceptable. In many cases it’s not. Prematurely optimizing it isn’t a great idea, but there’s a wealth of room for optimizing when it’s valuable to do so.

gitgud 5y ago
> Being able to batch state -> render updates based on priority even better still. Mobx [1] is pretty good for this, it batches updates that happen, making rendering more efficient. Also regarding rendering, react will update a component it it's state changes. It might update its children components, but if you pass them in as props, they won't be updated, as they're rendered in the parent component's context. This allows you to create complex applications with thousands of interactive components, and have quite good performance, as minimal rendering is performed. [1] https://mobx.js.org/react-integration.html https://mobx.js.org/react-integration.html
- eyelidlessness 5y ago
  Yep. Solid is too! Even so all of these abstractions need help when the computation itself is expensive and knowing whether to perform it is too. The ones best designed for that provide really clear APIs for how to take control where they’d otherwise handle it.
shrimp_emoji 5y ago
>what you just described can basically become unusable Oh, so like every JS interface ever. :D
- eyelidlessness 5y ago
  I mean, not really? My naive implementation in Solid required a few tweaks understanding the model and performs updates perceptually instantaneously on a perf sensitive input I use as a smoke test, without any of the tricks I expected to need, just its built in reactive primitives. The existing implementation performs the same computations on that data in about half a second, which feels like an eternity without special care to unblock the UI. JS is really fast. You just have to know how to use it, and when not to.
  - bryanrasmussen 5y ago
    Every programming language and application has the chance to become unusable, thus every JavaScript application has the opportunity to become unusable, obviously most do not because otherwise nothing would be usable on the Internet which, snark aside, things are usable even if they might annoy me. >You just have to know how to use it, and when not to. So, you have never had a JS application delivered over the web become unusable despite your attempts to only use it how and when you need to? Okay, well, congratulations either or in order or you've not been forced to use it for something you didn't want to or have just never been building something big with the technology and made a mistake? I mean my stuff generally doesn't become unusable, but generally is not always.
    - eyelidlessness 5y ago
      > So, you have never had a JS application delivered over the web become unusable despite your attempts to only use it how and when you need to? Of course I have, that’s not the point I was making. My point was that JS and the VMs it runs on are very fast, if you know how to use the language and when not to use it. That couldn’t possibly apply to apps you didn’t build. If I’d said C or whatever is fast if you know how to use it, I don’t think I’d get this comment about some horribly inefficient downloaded printer driver.
porker 5y ago
Would love to know what the app does. From the mentions of xpath all I can think is "visual xml editor"?
- bryanrasmussen 5y ago
  ideas: could be using data returned in XML format because there is no JSON endpoint for that particular data source. XPath is also nice for dealing with just about any complex markup tree, for example if you needed to extract data from serialized DOMs that were sent to your application somehow. How about SVG tools using XPath?
  - porker 5y ago
    Thanks, great ideas and I'd never considered XPath for SVG. I need to delve into that one further.
- eyelidlessness 5y ago
  It’s an implementation of ODK[1] extensions to the XForms specification[2]. The specific implementation is Enketo[3], which I was brought on to ODK to help maintain. Not exactly the spec I’d go with greenfield, but it’s been successfully in use for a decade with great impact. 1: https://getodk.org/ https://getodk.org/ 2: https://getodk.github.io/xforms-spec/ https://getodk.github.io/xforms-spec/ 3: https://enketo.org/ https://enketo.org/

gitgud 5y ago

> Being able to batch state -> render updates based on priority even better still. Mobx [1] is pretty good for this, it batches updates that happen, making rendering more efficient. Also regarding rendering, react will update a component it it's state changes. It might update its children components, but if you pass them in as props, they won't be updated, as they're rendered in the parent component's context. This allows you to create complex applications with thousands of interactive components, and have quite good performance, as minimal rendering is performed. [1] https://mobx.js.org/react-integration.html https://mobx.js.org/react-integration.html

eyelidlessness 5y ago
Yep. Solid is too! Even so all of these abstractions need help when the computation itself is expensive and knowing whether to perform it is too. The ones best designed for that provide really clear APIs for how to take control where they’d otherwise handle it.

shrimp_emoji 5y ago

>what you just described can basically become unusable Oh, so like every JS interface ever. :D

eyelidlessness 5y ago
I mean, not really? My naive implementation in Solid required a few tweaks understanding the model and performs updates perceptually instantaneously on a perf sensitive input I use as a smoke test, without any of the tricks I expected to need, just its built in reactive primitives. The existing implementation performs the same computations on that data in about half a second, which feels like an eternity without special care to unblock the UI. JS is really fast. You just have to know how to use it, and when not to.
- bryanrasmussen 5y ago
  Every programming language and application has the chance to become unusable, thus every JavaScript application has the opportunity to become unusable, obviously most do not because otherwise nothing would be usable on the Internet which, snark aside, things are usable even if they might annoy me. >You just have to know how to use it, and when not to. So, you have never had a JS application delivered over the web become unusable despite your attempts to only use it how and when you need to? Okay, well, congratulations either or in order or you've not been forced to use it for something you didn't want to or have just never been building something big with the technology and made a mistake? I mean my stuff generally doesn't become unusable, but generally is not always.
  - eyelidlessness 5y ago
    > So, you have never had a JS application delivered over the web become unusable despite your attempts to only use it how and when you need to? Of course I have, that’s not the point I was making. My point was that JS and the VMs it runs on are very fast, if you know how to use the language and when not to use it. That couldn’t possibly apply to apps you didn’t build. If I’d said C or whatever is fast if you know how to use it, I don’t think I’d get this comment about some horribly inefficient downloaded printer driver.

porker 5y ago

Would love to know what the app does. From the mentions of xpath all I can think is "visual xml editor"?

bryanrasmussen 5y ago
ideas: could be using data returned in XML format because there is no JSON endpoint for that particular data source. XPath is also nice for dealing with just about any complex markup tree, for example if you needed to extract data from serialized DOMs that were sent to your application somehow. How about SVG tools using XPath?
- porker 5y ago
  Thanks, great ideas and I'd never considered XPath for SVG. I need to delve into that one further.
eyelidlessness 5y ago
It’s an implementation of ODK[1] extensions to the XForms specification[2]. The specific implementation is Enketo[3], which I was brought on to ODK to help maintain. Not exactly the spec I’d go with greenfield, but it’s been successfully in use for a decade with great impact. 1: https://getodk.org/ https://getodk.org/ 2: https://getodk.github.io/xforms-spec/ https://getodk.github.io/xforms-spec/ 3: https://enketo.org/ https://enketo.org/