Thank you both! I now have a much better understanding on how React works. I need to update the related performance benchmarks, it would be interesting to see how they compare side-by-side on our use cases.
242 karma · joined September 15, 2012
On the HTML markup, there are many valid reasons you may want to use non-TABLE based tables:
- it allows better rendering control for infinite scrolling (DOM reuse, re-positioning, detached view for sticky header and column)
- it allows you to have real (CSS style-able) row groups, or if your structure is hierarchical, it allows you a better control to create a treetable (reduced rendering time if you expand a node and insert a bunch of rows in the middle).
- it allows you to have multiple grid systems inside the table (e.g. a detail row may use up the entire row, and it may have its own table inside, which you'd like to synchronize across multiple detail rows). I guess this later benefit is just redressing the fact that you do need to implement an independent grid system anyway :)
<div class="row">
<div class="cell">
<div class="align-left">
Value.
</div>
</div>
</div>
<div class="row">
<div class="cell">
<div class="align-center">
Value B.
</div>
</div>
</div>
DOM reuse is not the same thing moving a DOM subtree to a different place. DOM reuse is e.g. getting an already-rendered table row, binding a new value to it, and modifying only the DOM properties in the complex DOM structure that actually did change. E.g. you modify only an Element.text deep in the first column, and a few other values in the other columns. Or maybe you need to do more, but all you do is delta. You don't just annotate a DOM structure with a key at row level, as it is closer to a hash of the DOM, not speaking of the data-dependent event handlers.
Calculating the DOM (virtual or not) is expensive, compared to not calculating at all. Creating a virtual DOM structure and not using it afterward creates GC pressure, compared to not creating at all. We are talking about optimizations in the millisecond range. A large table with complex components inside will reveal the impacts of these small things.
DOM coordination is not just making the DOM writes in one go. Complex components like to interact with each other, depending on their position and size on their page, and the changes in the underlying structure. They read calculated style values, and act upon those values, sometimes causing reflows. And if such things happen at scale, forced reflows may cripple the performance, and coordinating such changes may be more crucial than the framework you are choosing.
I am sure that people who are familiar with React may have their way get these stuff. I have looked at it, and I haven't seen it to happen automatically, while with Angular.dart, I get it without effort.
My limited understanding of React is that it fails in (a), (b) and (c), and only limited measures can be applied to improve them. Re-creating the entire DOM on each update probably does not help. I have no information if (d) is possible with it.
I am using Angular.dart for a while now, and it can be used to get all of them in an optimal way.
Disclaimer: I'm working at Google.
1) The first part is exactly how the EU was designed: operate from one country, reduce your overhead. Maybe it is not Amazon's fault that they comply with the rules?
2) The second part is exactly how the Congress wanted its tax laws: if you bring money home, pay your taxes, if you don't, we are not involved. Maybe it is not Amazon's fault that they comply with the rules?
Edit: I shall add that the most interesting search problems are the ones where you need to join separate data sources, and in such cases it is not really the question of what kind of search solution you are using, rather what kind of async queue and data update you have. So the separated cluster is really about having a distributed queue between the 'data-master' and the 'search-master'.
"Some people actually advocate using Elasticsearch as a primary data store; I think this is somewhat less than advisable at present."
"The good news is that Elasticsearch is a search engine, and you can often afford the loss of search results for a while."
My personal favorite solution would reliably channel data from a Riak cluster to an ES cluster. Anyone knows if there is something like that out there?
On the actual critique: if you have had worked with eventually consistent database, a 'Call' record's presence is really a great pun on the 'call me maybe' phrase. I'm really sorry if you don't appreciate that part either.
[note]: This may have been true for a long time in the history. People were going to the US mainland because their conditions were bad enough, and anything would have been better elsewhere. I can understand that point of view, although e.g. my situation is on equal terms in the US vs my home country. However, I don't think it'll serve the US interest in the long run.
On the other hand, a close relative went to Singapore about the same time, and their immigration procedure was smooth, straighforward, everything in place, no barriers anywhere. Singapore wants to have qualified professionals, the US see them as numbers.
And for the wifes part: my wife has the same qualification as I have (two MSc in CS/IT), yet, she is not allowed to work. Not even with the proposed change in the law, as it requires to have ongoing greencard process, which itself may take years. So if you think that those shobby cheap visa workers just bring their freeriders with them, you are very far away from the reality.
Promoting US citizens just because they are US citizens may work for a while, but I doubt that it is a good long-term strategy.
I just don't get why the US wouldn't want qualified workers to get in the US. Singapore had this lesson learned well.
Disclaimer: I'm on H1B myself.
Just to single out a shortcomings I've recently found: multiple authors with multiple languages, defining short and long version of bio/tagline. The tagline is displayed at the article, which may be tagged with multiple contributors with different roles (author, translator, reviewer), while the author page displays the long version.
I've spent days to figure out what plugin/theme combination (Wordpress or Drupal) would enable me this single feature, and I couldn't figure it out.
Yesterday evening I gave up, and now I have <200 lines of code in Dart (using markdown and mustache), generating static pages that were annotated with metadata, doing just that. To be honest, I'd trade it any time for a decent CMS, I just can't find any.
It is not the transaction itself that is hard, it is the network partition. E.g. what happens if two network partition approve transactions, that wouldn't have been accepted if there were no partitions.
Thoughtful articles require time to write and edit, reviewers will spend time on them. Re-running a static site generator to publish them is a fraction of the total time it requires to write a good article.
If, on the other hand, you are not in for quality, then yes, time to publish may be important for you.
It seems that so far the best approach would be to write a dynamic web app that does what I want, and save the content with wget. Seriously, it seems easier than any of the hackery I need to do.
e.g. with archive pages like /<author>/<lang>/<yyyy>/<mm>/ and category pages like /<lang>/<cat>/<subcat>/
I fail to see any. I've tried to configure many of the available generators, but no one seem to have the same itch I have.