spicyj

26 ms·

241.
by spicyj 11y ago
What? This should work properly. If it doesn't, please file a detailed bug with info about your browser.
242.
by spicyj 11y ago
That's interesting, thanks for the references. I wonder if this is applicable to screen readers as well as Braille?
243.
by spicyj 11y ago
IE and Edge are much faster when appending nodes first (thus always appending empty nodes) but Chrome, Firefox, and Safari are similar speed regardless of the order. We do the former in IE and Edge only and the latter in all other browsers
244.
by spicyj 11y ago
Interesting, thanks. I had heard that calls from JS to C++ were cheap but calls from C++ to JS (such as if Array.prototype.map was implemented natively) were expensive.
245.
by spicyj 11y ago
Well, I did for a year and a half.
246.
by spicyj 11y ago
Yeah, you'd think that it would be a lot faster to avoid serializing and parsing everything, but it turns out to be not much difference. Not sure why.
247.
by spicyj 11y ago
We only used .innerHTML when creating new subtrees, which requires a reflow anyway when they're inserted. There are reasons that document.createElement is faster for us, but that's not one of them.
248.
by spicyj 11y ago
Yes, it is. React uses it to track identity of components in a list; it's significant especially when reordering children and affects both which DOM nodes get reused as well as whether this.state is preserved.
249.
by spicyj 11y ago
Yes, that's one prime motivation. In this particular PR, it's not clear that it could have been split up into any smaller logical commits since a lot of the code is interdependent.
250.
by spicyj 11y ago
Not quite -- it's so that the client can know which node is which. (When rendering on the client, it can just store a direct reference to each created node.)
251.
by spicyj 11y ago
Nope, it shouldn't affect you at all. (Otherwise it would have been noted in the blog post -- that should have all the info you need to upgrade.)
252.
by spicyj 11y ago
We didn't realize this would break. We're looking at cutting a 15.0.1 that puts React.__spread back with a warning.
253.
by spicyj 11y ago
I'm not sure how this is ironic? We were using one DOM API (.innerHTML) before; now we're using a different one.
254.
by spicyj 11y ago
> If React didn't have an explicit patent grant then there would be an implicit grant which does not have any retaliation clauses, and cannot be revoked. I'm not a lawyer. My understanding is that this is hypothetically possibl
255.
by spicyj 11y ago
That's possible. We haven't done much optimization on the dev build but I was planning to look for low-hanging fruit soon to see if there are any significant improvements we can make. I wouldn't have expected 15.0 to be much
256.
by spicyj 11y ago
I don't think we've ever promoted React based on file size. Smaller files are better but people tend to overemphasize JS file size -- gzipped, this latest release is 43k which is comparable to the size of an image or two on most w
257.
by spicyj 11y ago
(Replied to your top-level comment at https://news.ycombinator.com/item?id=11451283. )
258.
by spicyj 11y ago
Haven't benchmarked again, but it should be. This came from the document.createElement and reactid changes (and some associated internal refactors).
259.
by spicyj 11y ago
We updated the patent grant to be less restrictive in response to community feedback about a year ago (several months after the discussion you linked): https://github.com/facebook/react/commit/b8ba8c83f318b8
260.
by spicyj 11y ago
+1 to this. High-quality code from @mwiencek right out of the gate, and he was super responsive to my comments when I asked for changes. We're really grateful for the contribution.
261.
by spicyj 11y ago
We've open-sourced several other mostly-KA-specific parts of the site, including these: https://github.com/Khan/khan-exercises https://github.com/Khan/perseus https://github.com&#x
262.
by spicyj 11y ago
For sighted users it may be possible to differentiate, but whether "f of x plus 1" or "f times x plus 1" is read aloud is a significant difference.
263.
by spicyj 11y ago
KaTeX is more likely to be useful out of the box to other developers, whereas the source of the mobile apps is not going to be a drop-in component that's useful; it'd have to be used more as a learning opportunity by interested de
264.
by spicyj 11y ago
Yeah. I think that's inevitable with an XML syntax. XML is good at some things, but representing math expressions clearly is not one of them.
265.
by spicyj 11y ago
Not so much. https://bitquabit.com/post/separate-support-serve/
266.
by spicyj 11y ago
I assume most RSS readers don't support CSS (and webfonts) fully? If they did you could use KaTeX's server-rendering feature to embed the actual HTML, but otherwise images are probably your best bet.
267.
by spicyj 11y ago
Yes, you could try to build algorithms that turn that markup into semantic meaning but now we're almost talking about computer vision. I don't think a solution like that is likely to ever work reliably, and it's better to enc
268.
by spicyj 11y ago
"We need to get together with CSSWG/Houdini TF/etc to work out solutions that help those developers who actually solve the problem of math on the web." Unfortunately, Houdini seems to have deprioritized font metrics info
269.
by spicyj 11y ago
MathJax is very flexible and its output is certainly high-quality. However, it is difficult to configure and package in my experience, and it's pretty slow. We used it for a few years at Khan Academy before building KaTeX ( https:&#x2F
270.
by spicyj 11y ago
TeX is analogous to Presentation MathML but doesn't solve the accessibility concerns because the semantic intent of the TeX source isn't always clear. (How do you read a \phantom{}? Or how can you know that "\left( 7 \atop 3

More ›