What kind of "consistency" do bm25 indexes offer? e.g. I think ElasticSearch is eventually consistent and is constantly indexing in the background and classic Postgres GIN indexes have configuration like `gin_pending_list_limit` and `fastupdate` functionality to avoid slowdowns on insertions (and then you get slowdowns when an insert hits the threshold and triggers the catch-up indexing).
ParadeDB and pg_bm25 offer weak consistency. pg_bm25 doesn't slow down transactions for indexing, and like ElasticSearch it becomes become eventually consistent shortly after (typically at most a few seconds, altough your mileage may vary based on the amount of data modified in the transaction(s)).
The problem with this is that whatever you require() won't close over other variables/imports unless your preprocessor is straight up compiling JSX into JS and inserting into another JS file, which is kinda gross and eval-y.
If the rule is a) designers only touch .html/.hbs files and b) only developers touch the view/controller .js files, then if either of them change a property name from `{{displayName}}` to `{{display_name}}`, the whole thing breaks, which is the coupling React is trying to avoid by keeping these similar concerns within the same technology/file (JavaScript).
Because it's such a thin layer over JavaScript, you don't have to port/reimplment all the stuff that JavaScript has already solved to your templating language / abstraction of choice. I still prefer Handlebars, but JSX elegantly sidesteps lots of issues at the expense of not actually being real HTML and handling flow control stuff somewhat awkwardly, but you really gotta try it out to get a feel for the tradeoffs.
Thanks for slides. In this slide http://goo.gl/XDk0J0 you mentioned you would talk about alternatives to passing down callbacks later? Did I miss that in the deck or was that just spoken to?
There are heuristics to prevent recursing into obviously-removed/added elements (using component type and keys), but aside from that, there's always going to be a tradeoff between frameworks/libs that choose to track this granular information to know exactly where a change originated and what needs to be updated, vs libraries like React that don't set up any sort of observers or have any sort of knowledge about where the change originated from, and React has demonstrated that their approach is pretty fast due to the fact that live mutable DOM manipulation is the bottleneck and not purely JavaScript traversals.
My point is that the React marketing is "top down unidirectional data flow", and that you quickly reach the end of what you can do with that before needing to add a another perpendicular uni-directional data flow (which is Flux or one of its variants), which breaks the vanilla React paradigm and many of the simplifying assumptions implied within such a simplified system. Two flows, both uni-directional, but in different directions, and the top-down flow no longer has anywhere near the same degree of control once you've added Flux to your system.
> ...you quickly reach the end of what you can do with that before needing to add a another perpendicular uni-directional data flow (which is Flux or one of its variants)...
Can you expand on that? For a simple application without Flux, the data flow starts at the top-level component and ends at the bottom. That's unidirectional and we both agree.
For more complex applications that require Flux, the data flow starts at the top-level component which gets the state from the store and passes it to the child components, which may raise change events which will run the callback registered by the top-level component that gets the state from Store and passes it to the child components, which may raise change events and the cycle continues.
I don't see two flows, I don't see different directions and I'm not sure how anything is perpendicular.
