Sounds like premature optimization. /s
More seriously: maybe sometimes, late optimization can be a bad thing. That's where one should talk about performance design concerns.
“Implement text editor DOM updates manually instead of via React”
81–90 of 225 posts
Re: “Implement text editor DOM updates manually instead of via React”
#82Earlier quoted context omitted.
Thanks for your reply! I work in this field and have written lots of code, both mutable and immutable, declarative, OO and functional, to solve a variety UI problems. I've also written my own language-enabled editors using multiple techniques (see comment https://news.ycombinator.com/item?id=9117234 for the one I'm working on right now, but you can see https://www.youtube.com/watch?v=SAoRWmjl1i4 for an Eclipse-based…
It's a great question. All of this (immutability) only makes sense to even attempt if you believe that immutability is easier to reason about than mutability. If we don't agree there, then I have nothing more to add really. But assuming we agree, then there is the question of performance. In most applications, we have three tiers of time durations. Tier One: During an interaction/animation you must update the screen…
Holy cow this may be the most salient explanation of these various concerns I've seen.
Blocking for 1ms is as good as blocking for 13ms in Tier 1.
+1. Let's use all the resources we have available, and also make sure we understand where those resources are coming from. If one of our resources is user perception time we need to manage that just as we manage memory and CPU usage.
Re: “Implement text editor DOM updates manually instead of via React”
#83Earlier quoted context omitted.
>Over 1 Billion people use a React application everyday (Facebook + Instagram web) It's fun to actually see which parts of public websites are written with react by running this in the browser console: setInterval(function() { Array.prototype.slice.call(document.querySelectorAll('[data-reactid]')).forEach(function(element) { element.style.background = 'rgba(255,0,0,0.1)'; }) }, 500) Some pages to try it on: https://i…
Fake test. React Components don't always return a DOM element, also not every element shows up all the time, instead you should download the React dev tools. There are at least 30-40 top level components on Facebook. Nice try though.
You are of course correct that some React components will not be caught by this single-line test. It is impossible to truly know unless you are the author of the app, and that's the case even with React tools (e.g. you would not be able to identify my server-rendered components that are not mounted on the front-end).
The intent was not to provide a debugging tool - it's just to provide people with limited exposure to React a simple one-liner to help them understand what is meant when someone says Facebook/Instagram use React, and see some components in the wild. To that goal, using a simple test for data-reactid attribute will catch the overwhelming majority of in-the-wild use cases.
Re: “Implement text editor DOM updates manually instead of via React”
#84In 20/20 hindsight, using React for a text editor isn't a very good choice. Text editors, especially ones geared towards fast typists / programmers, are a double whammy in terms of being latency sensitive and needing to open large files.
Atom was already at a disadvantage on both counts on account of it being a Javascript app running inside chromeless Chrome. Making a browser do large things fast is difficult, and having React's paradigm of diffing a now huge virtual DOM running on every single keystroke can't really work.
React still works great for smaller and more demanding sites, though - but it does hit limits on large and complex DOM diffs at high frequencies with low latency demands.
Re: “Implement text editor DOM updates manually instead of via React”
#85Atom is awesome, but it feels like they are reinventing emacs only without terminal support and much slower. I use both editors but find myself continuing to go back to emacs b/c of a few features that I can't do without.
likewise. Out of curiosity, which features are you referring to?
Re: “Implement text editor DOM updates manually instead of via React”
#86Angular touted its declarative syntax, but really what does that give you? It saves a few strokes over something like Hey, how are you! And then in your javascript: controller.onStateChanged("name").set(function () { $(".myapp-name", container).html(state.name); }); The latter is more explicit and also declarative. It also gives you a lot more flexibility and is much more efficient than dirty-checking. React kind of…
Hey, {{name}} how are you!
now if you're really smart you'll write a compiler that desugar and inline everything so you get the best of both world: A declarative syntax and production speed.
Re: “Implement text editor DOM updates manually instead of via React”
#87Modifying the DOM is usually the bottleneck in web apps. To get a fast app (extreme simplification), you need to only apply the minimum set of mutations. It turns out that in a large codebase this is extremely hard to do. React asks the developer for a virtual representation and computes the diff between the previous one. In most situations, the time it takes to compute the set of mutations is negligible compared to…
React requirement today is that there can only be one version loaded at the same time, otherwise everything breaks. If you update React in Atom core, you run the risk of breaking all the plugins that were written for a different version of React.
Is this still an issue when you override `ID_ATTRIBUTE_NAME`?
require('react/lib/DOMProperty').ID_ATTRIBUTE_NAME = 'data-myproductid';
Re: “Implement text editor DOM updates manually instead of via React”
#88So is it fast now?
I doubt that Atom will ever expect my performance needs, but will give it a try.
Re: “Implement text editor DOM updates manually instead of via React”
#89Earlier quoted context omitted.
React is so much different from other frameworks, I feel. Someone that doesn't know React can basically come in and start working on a large app from Day 1. It is so much less frustrating than Angular, Backbone + Ember + handlebars, etc. You can continue to add features to a React application and not slow down. Also React isn't unproven. Over 1 Billion people use a React application everyday (Facebook + Instagram web…
>Over 1 Billion people use a React application everyday (Facebook + Instagram web) It's fun to actually see which parts of public websites are written with react by running this in the browser console: setInterval(function() { Array.prototype.slice.call(document.querySelectorAll('[data-reactid]')).forEach(function(element) { element.style.background = 'rgba(255,0,0,0.1)'; }) }, 500) Some pages to try it on: https://i…
That killed my facebook tab
Re: “Implement text editor DOM updates manually instead of via React”
#90Modifying the DOM is usually the bottleneck in web apps. To get a fast app (extreme simplification), you need to only apply the minimum set of mutations. It turns out that in a large codebase this is extremely hard to do. React asks the developer for a virtual representation and computes the diff between the previous one. In most situations, the time it takes to compute the set of mutations is negligible compared to…
I see it as similar to the C vs ASM discussion - usually it's faster to trust the compiler to optimise, but for very specific situations, it's faster to code your own assembly.