"They're smart enough to know they're not smart enough to build perfect abstractions, so they do a great job but leave escape hatches just in case"
The interest in Elm took a major hit after the compiler banned use of JS.
React on the other hand can wrap a JQuery calendar in a React component and from a programming point of view, using that component you would be none the wiser.
Also ports force everything to be async - and I am not talking just promises - I mean a new render per call response! So calculating 1+1 on a port requires generate a new render, and intercepting the result in a Redux-style handler, bubbling that into a component.
While you won't need to do 1+1 via ports, you might need to use a synchronous web-api feature that has not been ported to elm, or even use a math package to multiply some matrices.
Pros:
* I have generic "zoom/pan" implemented. I did this by making a generic ChartContainer with 5 zones - top, right, bottom, left, content - and you specify just the size of the non-content zones (if displaying them at all) and otherwise it behaves responsively (i.e. CSS style on the container is respected in the internal math). When you scroll the left/content/right vertically, or the top/content/bottom horizontally, it virtually scrolls the other components for you. It also of course handles the math, each area of the 5 is passed a DOMRect describing how big of SVG it can render
* I have smart edge routing component on a graph; if you are doing the math yourself on how to position the SVG elements, you can easily describe that graph, so smart edge routing is free
* my library has themes via CSS vars, and the components written in this way are obviously automatically themed
Cons:
* it's a bit verbose for sure, takes some small time and focus. After the initial investment in ChartContainer though, they work freaking awesome
* D3 graphs often come with sweet animations and such, I don't have any capability to emulate this today, I hate to do performance-heavy things like manually doing math every frame in a hooks-based way, and I don't want MobX in my component library
* you sort of lose access to the D3 ecosystem, nothing is free
To be honest, I think I have made a top-tier Gantt with the smart edge routing and zoom, my Graph looks sharp too, and for overhead views it's super nice to be able to zoom and pan and show rulers on the side (imagine showing factory layout, or a board layout, etc). Otherwise, if you are doing more traditional pretty eye-catching stuff, it's not quite meant for that approach
You may want to check out this library: https://airbnb.io/visx/ They converted a ton of d3 features into proper React components
One of the promises of switching from class-based components to function-based was supposed to be an automatically applied version of shouldComponentUpdate, which AFAIK was never fulfilled.
- 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.
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.
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?
Oh, so like every JS interface ever. :D
>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.
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.
that's why I prefer Solid instead of React. For client side stuff, Solid is sooo much better than React.
You've now described the Web Components crusade which, among other things, engages in actual gaslighting.
Honestly, I haven't. The only potential caveat I can think of is when you have some non-reactive legacy code you want to embed inside a React component... but even then React's escape hatches are more than sufficient.
If you're really worrying about when your component renders or re-renders it's probably because there are other issues with your app.