Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Discussion on usage of phosphor in ipython #8239
I will summarize some of the points discussed in other issues to get a centralized issue about this topic.
First of all. What is phosphor?
What phosphor is not:
Arguments in favor of using phosphor in ipython:
Arguments against using phosphor in ipython:
Answer below here.
Tied to the "young project" issue, one of my main concerns is that buying into a framework carries a lot of weight. A framework necessarily has opinions and fundamental assumptions that can have major performance and development implications.
Community is also hugely important - for attracting developers, for battle-testing a platform, for providing support / answers on SO, etc. (related to documentation, large-scale deployments, tutorials, etc.). And far beyond that, the module ecosystem. React has some really well-thought-out solutions to common problems (thinking specifically of react-router), and I fear that in phosphor, we'd end up having to invent a whole ton of things. Angular and Ember also have great communities and module ecosystems.
I'm coming from a React background, and that's certainly my framework of choice, especially for a big project such as this. Things like inter-component communication, effective modularity, lots of optimization -- facebook and others have spent years working on this.
About the arguments in favor of phosphor:
I'm not sure I understand this one. Is this "having multiple things in a single browser tab"?
Having a smaller surface for bugs is great, but who's to say this doesn't end up with lots more boilerplate than using a different framework?
This is true for any framework using a virtual dom system, including React
Is awesome. And it gives us some degree of confidence that the code doesn't have a certain class of errors. Facebook has taken a similar approach with flow, which shares similarities with Typescript but is reportedly faster and has a richer type system.
And he presumably has lots of experience with ipython, then. I'm assuming this is helpful because he has a vested interest in helping ipython succeed. And could also work closely with ipython development to address needs, fix bugs, etc.
Related, though: is working on phosphor his full-time job, or does he have other responsibilities too? And is there anyone else at Bloomberg who is responsible for phosphor? (it wouldn't seem so from the commit log). Is Bloomberg committed to phosphor as an open source framework?
Angular, Ember, React -- all have a team of people working full-time to improve them. Both Angular and React have substantial corporate backing, with major interests and explicit commitment.
@rsmith31415 I appreciate you taking the time to write this up! However, I don't think you yet have clear picture of what Phosphor is and isn't, and I would appreciate it if you would refrain from making absolutist statements until your understanding of things improves. Otherwise, it creates FUD which I have to go back and correct and explain away to newcomers. I'm absolutely more than happy to expound on technical details at any level you wish, but if something is not absolutely clear to you, please leave it as a question or a clearly indicated opinion.
With that said...
No, they don't. Most examples are demonstrations of the various panel layouts, which have nothing to do with the virtual DOM.
Yes is it, and yes it does. It's not a complete solution by itself, but its part of the larger solution. I pointed you to the actual line in the Chrome C++ source code which makes the optimization. I haven't taken the time to search through Firefox's code for a similar optimization, but I would be astonished if Firefox (and IE) did not make the same trivial optimization.
Gauging performance based on the FPS on those examples is a bit silly since both are so simple they run at 60fps. Phosphor shines when making interactive layout changes to the DOM, like dragging a splitter handler, re-configuring a layout, or adding and removing large blocks of content. Since Phosphor never reads geometry from the DOM, there are never any inline reflows. As I showed in this example, Phosphor is ~40x faster than CodePen when dragging a splitter handle. Sure, those examples both run at 60FPS, but CodePen is right on the limit consuming 16ms in its mousemove event handler. Phosphor requires less than a millisecond. That leaves a huge block of time remaining for the application to do anything it needs while still maintaining the 60fps time budget. I'd call that high performance.
Can you elaborate on what you mean by this?
JSX is optional, but as of React 0.13, the no-JSX option is exceedingly verbose (IMO). Just FYI.
You can put any content you want inside both Phosphor widgets and Phosphor virtual DOM components. No part of the framework forces you to adopt one particular way of doing things.
I disagree. We've already done this in a project which I cannot share publicly. Even without any changes to the notebook UI itself, performance was good, and (due to layout boundaries) the non-notebook parts of the app were perfectly speedy.
These are all easily rectified.
Yes. See my comment 3-steps above.
There seems to be some confusion because phosphor has two distinct parts.
Widgets/panels use JS instead of CSS for layout. I don't know much about this side of things, but in earlier discussions @ellisonbg was of the opinion that they are needed by Jupyter. These widget/panels provide a toolbox for high level layout management, e.g. providing a tiling window manager in the browser. There does not seem to be an alternative library that provides this, even leaving aside the JS vs CSS issue.
Then there is the components library, which is a virtual dom library. It is very similar to react, but gives slightly more manual control.
I was referring to the components library, @takluyver was referring to widgets/panels.
Regarding how much of the layout would be done with phoshpor widgets/panels: probably only the highest levels of they layout would use widgets/panels, e.g. the bottom pane that contains docstrings might be a widget/panel. Notebook cells would almost certainly not be widgets/panels.
I hope this clears up some of the confusion.
Really they are separate decisions, because we could choose to use phosphor for the high level layout, and react for everything else, for example.
@sccolbert Well, part of the reason to write this issue is to discuss some aspects that are not really clear about phosphor. So I guess you need to explain certain things and I will be more than happy to amend my original message. Also, keep in mind that I was taking the main points from other people to condense all the discussion in a single issue.
Let me go through each of your points.
I was referring precisely to that big implementation "detail". What you mean by "CSS layout algorithms are not involved"? Do you mean that there is not a complex box model? You know CSS is involved when you use
Fair enough. Some of your examples involve the virtual DOM.
That is misleading. As you said, it is a trivial optimization that browsers do. A library can't claim to be a high performance library because it is using
Not on my computer. That's why I talked about both tests.
That's an interesting point. I will update the original comment with that.
As I said, you're comparing a three year old web service with a demo. That's hardly a fair comparison.
What do you mean? Did you already use the Ipython notebook in phosphor?
But in the meantime, that is something we have to consider as a very serious issue.
That was a question for the people involved in rewriting the components of the notebook, but it is good to know your ideas about it.
@KesterTong Thanks. Your answer clears up a lot.
As you can see, I would still argue about "Widgets/panels use JS instead of CSS for layout." because inline styles (even if it is only
Yes, that is the idea that @ellisonbg and others are pursuing.
Another question. What happens if he gets another job? That is the danger of adopting a project with a single developer.
I don't really think it would inhibit the use of a framework, at least in the widget/panel part which seems to have more flexibility in that regard. I think we get an abstraction to create very complicated and modular layouts (even though layout shouldn't be complicated at all) and we lose the conventional path that has been used to build websites (although Angular, React and friends are not really conventional).
This comment makes it clear that your understanding of this topic is sophomoric. There is nothing to "download" or "cache" when writing to the inline style object of a node. You can read all about it here.
Inline styles are not going to generate more reflows. That point is complete bollocks. You'll always get a reflow when changing the geometry of something in DOM, no matter how you make that change (ignoring GPU animation layers which aren't relevant here). The key is to only get one reflow per change you want to make, and to have that one reflow be arrested as soon as possible. This is exactly what Phosphor does, and you've already been shown examples and timings which back that up.
I'm not making the claim that Phosphor is high performance because it uses absolute positioning. It's high performance because of the collective combination of efficient layout algorithms and intelligent manipulation of the DOM. Using absolute positioning is one part of that.
Why do you keep claiming that "that browser feature is supposed to improve performance when you have a small number of children", do you have any proof of this? Absolute positioning has been around since the 'position' property was introduced in CSS2 all the way back in 1998.
No one here has ever suggested absolutely positioning every single node in the notebook. As @KesterTong pointed out, Phosphor panels are used for the high-level layout scaffolding of the app. I've never sold it as a "use this for everything" library. It's a tool which should be used where appropriate.
I took an example you provided as evidence to show that it's easy to do these sorts of things without Phosphor, and compared the performance of an isolated interaction in that example with the same interaction in Phosphor. Neither CodePen nor Phosphor had any content in the panels which were being resized. CodePen generated several inline reflows compared to Phosphor's zero, which caused it to be 40x slower at the same task. What exactly is unfair about that? That the results were not what you wanted?
This is not an elaboration. It's a restatement of the same thing with some more context. Why do you feel this way? Why do you think using Phosphor (or another layout library) will lead to the same issues?
Yes. @ellisonbg has seen it.
Your own example again refutes your claims. Cloud 9 uses it's own large in-house library, and if you had taken the time to look for yourself, you would have seen that it relies on inline styles and absolute positioning of the panels as well:
I think you need to read more carefully. That is exactly my point. The browser needs to read inline styles every time you load the page. When you use style sheets, the browser is able to cache that style sheet.
It is a bit more complicated than "reflows occur only when changing geometry". Depending on the browser, a change in borders, background, class, display property or simply adding a rule will trigger a reflow, That's why the general recommendation (from browsers) is to reduce the number of inline styles to avoid reflows.
Well, you can claim that an efficient layout algorithm is what makes Phosphor a high performance library, but the thing that was shown as the main feature definitely is not enough.
Because that was the main purpose. The situation in which you get the least number of reflows is when you have a small number of children. When this condition is not met, a large number of nodes can propagate their changes until they reach the root element (in this case, the element with
It was a question, since I saw that you can use it for images or select elements, I was wondering about the intended level of granularity.
Sure. A random example.
I don't need to write a library to do the 5%. Not everything needs a library. It would be nice to have some benchmarks before claiming anything about performance and obviously, when using an abstraction, you lose flexibility.
Excellent. Why don't you make a pull request?
That statement is correct only if "large in-house library" is equivalent to "we write code according to our requirements".
You continue to make unsubstantiated claims, and at this point I feel there is little to no benefit to continuing the conversation. If at some point you can provide a compelling alternative to Phosphor, I'm all ears. Until then, have fun with your opinions. I have real code to write.
I think it's time to wrap this discussion up. @rsmith31415, I appreciate your input, and I think the discussion has in many ways been very useful. Having a public record of these points, together with some of the detail provided in #7784 and #7997, is very useful in the long run: it helps clarify certain points, and it will serve as a reference to come back to in the future, for ourselves and for others. But at this point, it seems the discussion isn't really providing much more useful understanding. For one thing, it's important to note some context:
From this discussion, the one concern I feel is worth highlighting, is the issue of lack of tests in phosphor. For me, that does continue to be a serious concern. I do hope that @sccolbert will be able to put it high on the priority list, before we start using it in anger, and we can certainly help out as much as possible. Tutorials/docs would obviously be great to have, but less critical at this point.
I'm closing the issue to signal that this is a choice that has been made. I won't lock it as I imagine there may be useful feedback yet, but for now, we're committed to giving Phosphor a fair shot. If this proves to be a problem, we'll re-evaluate and adjust accordingly. But we need to move forward.
@fperez Notice that @ellisonbg agreed to have a separate issue to discuss this topic, although I think you're right; this quickly devolved into something definitely not useful because understandably @sccolbert felt the need to "correct the record" and I decided to "correct the corrections".
Initially it was a cause of concern because people were talking about other excellent frameworks and suddenly, the conversation focused on phosphor without really knowing what phosphor was and many inaccurate claims didn't help the process. Furthermore, it was already influencing a PR I was working on (#7997) although that was finally resolved.
It would have been nice to hear from you a lot earlier to announce this decision as definitive. I'm sure most people would have understood it as the end of the discussion.
@rsmith31415, sorry for not pitching in earlier... I was watching the original discussion on #7997 on Tuesday, and it actually looked like there was still some good info coming out of there. It was only yesterday night that it started to become clear that this wasn't producing much more light than heat, and unfortunately I had a horribly complicated day until just a couple of hours ago.
But your point is absolutely correct, it's on me not to have communicated that better, even on the mailing list. For that I apologize, esp. if it wasted some of your time or that of others.
I do want to thank you and the others: even with a bit of unnecessary noise, there was a very thorough discussion of the tooling that will serve as a useful reference for the future.
And I do remain very worried about the tests, so let's not forget that ;)