Discussion on usage of phosphor in ipython #8239

Closed
rsmith31415 opened this Issue Apr 3, 2015 · 12 comments

Comments

Projects
None yet
6 participants
@rsmith31415
Contributor

rsmith31415 commented Apr 3, 2015

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?

  • It is a tabbed/paneled layout system written in TypeScript, in which CSS styles are managed on the fly using Javascript. The purpose is to build an IDE (such as Eclipse or Visual Studio) in the browser.
  • A tab/panel can contain an application (in our case, a notebook, terminal, editor or debugger) and the purpose is to have several tabbed notebooks with a terminal/debugger/editor in the same browser tab. Phosphor supports nested layout hierarchies of any depth.
  • Phosphor is "unopinionated" about the creation of a virtual DOM inside its panels, however, most (if not all) examples use a virtual DOM and I think that is the preferred option in our case.

What phosphor is not:

  • It is not a way to bypass CSS.
  • It is not a way to improve performance by using "layout stops" to render only some parts of the page that changed. That is a browser feature when using position: absolute; . Therefore, it doesn't address "performance issues associated with having multiple notebooks/terminals/text editors in a single browser tab".
  • It is probably not accurate to call it a high performance framework. However, it is trying to be efficient given the fact that "phosphor never reads geometry from the DOM, there are never any inline reflows". According to Chris' comparison between phosphor and CodePen, the performance in FPS is very similar (in Windows.) The comparison I did (in Linux) shows that phosphor has paint rectangles over the ideal FPS (which means that the interface is laggy). However, its mouseover events after resizing are faster. By the way, the comparison was incidental. We need to have a website built on phosphor to have a fair comparison, but this is what we have so far.
  • It is not the only way to build a tabbed/paneled layout. CSS + a bit of Javascript is an approach more than capable to build that interface without abstractions.
  • It is not a solution to the problem of "fix one issue, introduce another" in CSS. If you keep solving layout issues with Javascript when it is not necessary, the same problem will arise (with or without phosphor).

Arguments in favor of using phosphor in ipython:

  • It is a good fit for the implementation of several components in a single tab.
  • Written in TypeScript.
  • Some people don't like JSX and phosphor doesn't force you to do so (although, to be fair, JSX is optional in react).
  • phosphor's libraries are very small.
  • Chris works for Bloomberg (which works a lot with Ipython)
  • According to @KesterTong, it is possible to use the virtual but also regular DOM manipulation.

Arguments against using phosphor in ipython:

  • Very young project.
  • It is very unlikely to get a good user experience if we embed several notebooks (+ other components) in a single browser tab. There are plans to address performance issues.
  • No tests.
  • No documentation. There is API documentation, though.
  • No websites or tutorials.
  • No large-scale deployments (except Bloomberg, but that certainly is not good enough)
  • Chris is the only person contributing to phosphor.

Open questions:

  1. Phosphor is able to work with react.js or incorporates a react-like framework? @KesterTong said that phosphor is "the good parts" of react but @takluyver said that phosphor is able to interoperate with frameworks like react.

UPDATE: Phosphor incorporates a react-like framework in its virtual dom library and also is able to work with other frameworks in its widget/panel part. Thanks @KesterTong, @sccolbert.

  1. What level of granularity do you pretend to have using Phosphor's components? For example, you can use a component for the whole notebook and stop there. However, it is also possible to use a component for the menu and another for images and another for the output of cells, etc.

Answer below here.

ping @ellisonbg , @takluyver , @minrk, @KesterTong, @Carreau, @jasongrout, @sccolbert, @jaredly, @bollwyvl.

@minrk minrk added this to the no action milestone Apr 3, 2015

@jaredly

This comment has been minimized.

Show comment
Hide comment
@jaredly

jaredly Apr 3, 2015

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:

It is a good fit for the implementation of several components in a single tab.

I'm not sure I understand this one. Is this "having multiple things in a single browser tab"?

phosphor's libraries are very small

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?

virtual dom + regular DOM manipulation

This is true for any framework using a virtual dom system, including React

Typescript

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.
With the new notebook being written in Typescript, phosphor certainly has integration out of the box.

Chris works for Bloomberg (which does lots of ipython)

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.

TL;DR

There are lots of javascript frameworks, and I would argue that it doesn't make sense to try to build a large-scale app without a framework. Phosphor, as "a tabbed/paneled layout system", doesn't seem to be on the same level as a framework. But it would(might?) inhibit the use of a framework. So basically: what are we gaining, and what are we losing?

jaredly commented Apr 3, 2015

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:

It is a good fit for the implementation of several components in a single tab.

I'm not sure I understand this one. Is this "having multiple things in a single browser tab"?

phosphor's libraries are very small

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?

virtual dom + regular DOM manipulation

This is true for any framework using a virtual dom system, including React

Typescript

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.
With the new notebook being written in Typescript, phosphor certainly has integration out of the box.

Chris works for Bloomberg (which does lots of ipython)

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.

TL;DR

There are lots of javascript frameworks, and I would argue that it doesn't make sense to try to build a large-scale app without a framework. Phosphor, as "a tabbed/paneled layout system", doesn't seem to be on the same level as a framework. But it would(might?) inhibit the use of a framework. So basically: what are we gaining, and what are we losing?

@sccolbert

This comment has been minimized.

Show comment
Hide comment
@sccolbert

sccolbert Apr 3, 2015

@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...

It is a tabbed/paneled layout system written in TypeScript, in which CSS styles are managed on the fly using Javascript.

The layout of widgets (not virtual DOM components) is managed with Javascript. The user is still free to style their widget however they want. The fact that Phosphor is using absolute position and writing to the inline style object is an implementation detail. CSS layout algorithms are not involved.

however, most (if not all) examples use a virtual DOM

No, they don't. Most examples are demonstrations of the various panel layouts, which have nothing to do with the virtual DOM.

It is not a way to improve performance by using "layout stops" to render only some parts of the page that changed. That is a browser feature when using position: absolute; . Therefore, it doesn't address "performance issues associated with having multiple notebooks/terminals/text editors in a single browser tab".

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.

It is probably not accurate to call it a high performance framework. According to Chris' comparison between phosphor and CodePen, the performance in FPS is very similar (in Windows.)

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.

It is not the only way to build a tabbed/paneled layout. CSS + a bit of Javascript is an approach more than capable to build that interface without abstractions.

This true depending on your definition of "equivalent interface". Phosphor layouts allow the developer to express size constraints which cannot be achieved with CSS alone. So if you want to replicate Phosphors layouts, you'll have to write some Javascript. If you want to replicate them efficiently, you'll end up with something which looks a heck of a lot like Phosphor.

It is not a solution to the problem of "fix one issue, introduce another" in CSS. If you keep solving layout issues with Javascript when it is not necessary, the same problem will arise (with or without phosphor).

Can you elaborate on what you mean by this?

Some people don't like JSX and phosphor doesn't force you to do so (although, to be fair, JSX is optional in react).

JSX is optional, but as of React 0.13, the no-JSX option is exceedingly verbose (IMO). Just FYI.

According to @KesterTong, it is possible to use the virtual but also regular DOM manipulation.

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.

It is very unlikely to get a good user experience if we embed several notebooks (+ other components) in a single browser tab. There are plans to address performance issues.

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.

No tests. No documentation. No websites or tutorials.

These are all easily rectified.

Is Phosphor is able to work with react.js or incorporates a react-like framework?

Yes. See my comment 3-steps above.

What level of granularity do you pretend to have using Phosphor's components?

Whatever level suits the particular use case. Phosphor is a small-ish set of UI tools to make writing large desktop-style web applications not suck. Use the right tool for the job. Sometimes, that will mean using Phosphor widgets, sometimes Phosphor components, sometimes embedding an existing Javascript library like CodeMirror. All of these things play nicely together, and the few rough edges which still exist are being actively smoothed.

@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...

It is a tabbed/paneled layout system written in TypeScript, in which CSS styles are managed on the fly using Javascript.

The layout of widgets (not virtual DOM components) is managed with Javascript. The user is still free to style their widget however they want. The fact that Phosphor is using absolute position and writing to the inline style object is an implementation detail. CSS layout algorithms are not involved.

however, most (if not all) examples use a virtual DOM

No, they don't. Most examples are demonstrations of the various panel layouts, which have nothing to do with the virtual DOM.

It is not a way to improve performance by using "layout stops" to render only some parts of the page that changed. That is a browser feature when using position: absolute; . Therefore, it doesn't address "performance issues associated with having multiple notebooks/terminals/text editors in a single browser tab".

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.

It is probably not accurate to call it a high performance framework. According to Chris' comparison between phosphor and CodePen, the performance in FPS is very similar (in Windows.)

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.

It is not the only way to build a tabbed/paneled layout. CSS + a bit of Javascript is an approach more than capable to build that interface without abstractions.

This true depending on your definition of "equivalent interface". Phosphor layouts allow the developer to express size constraints which cannot be achieved with CSS alone. So if you want to replicate Phosphors layouts, you'll have to write some Javascript. If you want to replicate them efficiently, you'll end up with something which looks a heck of a lot like Phosphor.

It is not a solution to the problem of "fix one issue, introduce another" in CSS. If you keep solving layout issues with Javascript when it is not necessary, the same problem will arise (with or without phosphor).

Can you elaborate on what you mean by this?

Some people don't like JSX and phosphor doesn't force you to do so (although, to be fair, JSX is optional in react).

JSX is optional, but as of React 0.13, the no-JSX option is exceedingly verbose (IMO). Just FYI.

According to @KesterTong, it is possible to use the virtual but also regular DOM manipulation.

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.

It is very unlikely to get a good user experience if we embed several notebooks (+ other components) in a single browser tab. There are plans to address performance issues.

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.

No tests. No documentation. No websites or tutorials.

These are all easily rectified.

Is Phosphor is able to work with react.js or incorporates a react-like framework?

Yes. See my comment 3-steps above.

What level of granularity do you pretend to have using Phosphor's components?

Whatever level suits the particular use case. Phosphor is a small-ish set of UI tools to make writing large desktop-style web applications not suck. Use the right tool for the job. Sometimes, that will mean using Phosphor widgets, sometimes Phosphor components, sometimes embedding an existing Javascript library like CodeMirror. All of these things play nicely together, and the few rough edges which still exist are being actively smoothed.

@KesterTong

This comment has been minimized.

Show comment
Hide comment
@KesterTong

KesterTong Apr 3, 2015

Contributor

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.

Phosphor is able to work with react.js or incorporates a react-like framework? @KesterTong said that phosphor is "the good parts" of react but @takluyver said that phosphor is able to interoperate with frameworks like react.

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.

Contributor

KesterTong commented Apr 3, 2015

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.

Phosphor is able to work with react.js or incorporates a react-like framework? @KesterTong said that phosphor is "the good parts" of react but @takluyver said that phosphor is able to interoperate with frameworks like react.

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.

@rsmith31415

This comment has been minimized.

Show comment
Hide comment
@rsmith31415

rsmith31415 Apr 3, 2015

Contributor

@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.

The layout of widgets (not virtual DOM components) is managed with Javascript. The user is still free to style their widget however they want. The fact that Phosphor is using absolute position and writing to the inline style object is an implementation detail. CSS layout algorithms are not involved.

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 position: absolute;, height, width, innerWidth, innerHeight, etc. By the way, that detail is important because when you declare your styles, the browser caches the style sheet. On the contrary, inline styles always need to be downloaded. It is also important because it is more likely to generate a reflow by using inline styles.

No, they don't. Most examples are demonstrations of the various panel layouts, which have nothing to do with the virtual DOM.

Fair enough. Some of your examples involve 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.

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 position: absolute;. In that case, the modal component of Jquery is also high performance and everything that uses position: absolute; is suddenly "high performance". Furthermore, as I explain in the other issue, that browser feature is supposed to improve performance when you have a small number of children, but in our case, we would have a large number of nodes in each panel. Therefore, this is not even the beginning of a solution. However, I agree that it doesn't make performance worse.

Gauging performance based on the FPS on those examples is a bit silly since both are so simple they run at 60fps.

Not on my computer. That's why I talked about both tests.

Since Phosphor never reads geometry from the DOM, there are never any inline reflows.

That's an interesting point. I will update the original comment with that.

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.

As I said, you're comparing a three year old web service with a demo. That's hardly a fair comparison.

This true depending on your definition of "equivalent interface". Phosphor layouts allow the developer to express size constraints which cannot be achieved with CSS alone. So if you want to replicate Phosphors layouts, you'll have to write some Javascript. If you want to replicate them efficiently, you'll end up with something which looks a heck of a lot like Phosphor.

Yes, but no one said we intended to do a tabbed/paneled interface without Javascript (the difference lies between 100% and 5% of Javascript).

Can you elaborate on what you mean by this?

Sure. @takluyver said a couple of times that core members of Ipython wanted to explore alternatives to the way they are writing the front-end because they are tired of fixing one issue and in the process, introduce another issue, particularly in relation to CSS. That is why I said "If you keep solving layout issues with Javascript when it is not necessary, the same problem will arise (with or without phosphor)."

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.

What do you mean? Did you already use the Ipython notebook in phosphor?

These are all easily rectified.

But in the meantime, that is something we have to consider as a very serious issue.

Yes. See my comment 3-steps above.

Great.

Whatever level suits the particular use case. Phosphor is a small-ish set of UI tools to make writing large desktop-style web applications not suck. Use the right tool for the job. Sometimes, that will mean using Phosphor widgets, sometimes Phosphor components, sometimes embedding an existing Javascript library like CodeMirror. All of these things play nicely together, and the few rough edges which still exist are being actively smoothed.

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.

Contributor

rsmith31415 commented Apr 3, 2015

@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.

The layout of widgets (not virtual DOM components) is managed with Javascript. The user is still free to style their widget however they want. The fact that Phosphor is using absolute position and writing to the inline style object is an implementation detail. CSS layout algorithms are not involved.

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 position: absolute;, height, width, innerWidth, innerHeight, etc. By the way, that detail is important because when you declare your styles, the browser caches the style sheet. On the contrary, inline styles always need to be downloaded. It is also important because it is more likely to generate a reflow by using inline styles.

No, they don't. Most examples are demonstrations of the various panel layouts, which have nothing to do with the virtual DOM.

Fair enough. Some of your examples involve 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.

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 position: absolute;. In that case, the modal component of Jquery is also high performance and everything that uses position: absolute; is suddenly "high performance". Furthermore, as I explain in the other issue, that browser feature is supposed to improve performance when you have a small number of children, but in our case, we would have a large number of nodes in each panel. Therefore, this is not even the beginning of a solution. However, I agree that it doesn't make performance worse.

Gauging performance based on the FPS on those examples is a bit silly since both are so simple they run at 60fps.

Not on my computer. That's why I talked about both tests.

Since Phosphor never reads geometry from the DOM, there are never any inline reflows.

That's an interesting point. I will update the original comment with that.

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.

As I said, you're comparing a three year old web service with a demo. That's hardly a fair comparison.

This true depending on your definition of "equivalent interface". Phosphor layouts allow the developer to express size constraints which cannot be achieved with CSS alone. So if you want to replicate Phosphors layouts, you'll have to write some Javascript. If you want to replicate them efficiently, you'll end up with something which looks a heck of a lot like Phosphor.

Yes, but no one said we intended to do a tabbed/paneled interface without Javascript (the difference lies between 100% and 5% of Javascript).

Can you elaborate on what you mean by this?

Sure. @takluyver said a couple of times that core members of Ipython wanted to explore alternatives to the way they are writing the front-end because they are tired of fixing one issue and in the process, introduce another issue, particularly in relation to CSS. That is why I said "If you keep solving layout issues with Javascript when it is not necessary, the same problem will arise (with or without phosphor)."

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.

What do you mean? Did you already use the Ipython notebook in phosphor?

These are all easily rectified.

But in the meantime, that is something we have to consider as a very serious issue.

Yes. See my comment 3-steps above.

Great.

Whatever level suits the particular use case. Phosphor is a small-ish set of UI tools to make writing large desktop-style web applications not suck. Use the right tool for the job. Sometimes, that will mean using Phosphor widgets, sometimes Phosphor components, sometimes embedding an existing Javascript library like CodeMirror. All of these things play nicely together, and the few rough edges which still exist are being actively smoothed.

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.

@rsmith31415

This comment has been minimized.

Show comment
Hide comment
@rsmith31415

rsmith31415 Apr 3, 2015

Contributor

@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 position, height, width, etc) are CSS styles.

There does not seem to be an alternative library that provides this, even leaving aside the JS vs CSS issue.

That's true, but maybe because you usually don't need a library to deal with layout even for IDEs in the browser (e.g. codiad, cloud9.)

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.

Very reasonable.

Contributor

rsmith31415 commented Apr 3, 2015

@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 position, height, width, etc) are CSS styles.

There does not seem to be an alternative library that provides this, even leaving aside the JS vs CSS issue.

That's true, but maybe because you usually don't need a library to deal with layout even for IDEs in the browser (e.g. codiad, cloud9.)

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.

Very reasonable.

@rsmith31415

This comment has been minimized.

Show comment
Hide comment
@rsmith31415

rsmith31415 Apr 3, 2015

Contributor

@jaredly

I'm not sure I understand this one. Is this "having multiple things in a single browser tab"?

Yes, that is the idea that @ellisonbg and others are pursuing.

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?

Another question. What happens if he gets another job? That is the danger of adopting a project with a single developer.

But it would(might?) inhibit the use of a framework. So basically: what are we gaining, and what are we losing?

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).

Contributor

rsmith31415 commented Apr 3, 2015

@jaredly

I'm not sure I understand this one. Is this "having multiple things in a single browser tab"?

Yes, that is the idea that @ellisonbg and others are pursuing.

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?

Another question. What happens if he gets another job? That is the danger of adopting a project with a single developer.

But it would(might?) inhibit the use of a framework. So basically: what are we gaining, and what are we losing?

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).

@sccolbert

This comment has been minimized.

Show comment
Hide comment
@sccolbert

sccolbert Apr 3, 2015

@rsmith31415

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 position: absolute;, height, width, innerWidth, innerHeight, etc. By the way, that detail is important because when you declare your styles, the browser caches the style sheet. On the contrary, inline styles always need to be downloaded. It is also important because it is more likely to generate a reflow by using inline styles.

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.

Phosphor layouts compute the x, y, width, and height (in pixels) of each widget entirely in Javascript and write those values directly to the style object. The browser does not compute them. The only part of the CSS engine which is involved with this is the cascade (i.e. the style recomputation in the timeline), which is a trivial computation because the inline style object has the highest precedence (aside from !important).

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.

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 position: absolute;. In that case, the modal component of Jquery is also high performance and everything that uses position: absolute; is suddenly "high performance". Furthermore, as I explain in the other issue, that browser feature is supposed to improve performance when you have a small number of children, but in our case, we would have a large number of nodes in each panel. Therefore, this is not even the beginning of a solution. However, I agree that it doesn't make performance worse.

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.

As I said, you're comparing a three year old web service with a demo. That's hardly a fair comparison.

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?

Yes, but no one said we intended to do a tabbed/paneled interface without Javascript (the difference lies between 100% and 5% of Javascript).

So then find or write a library which does it with 5% Javascript and has the same performance and flexibility. Otherwise, you're just wasting people's time and energy with this nonsense. I have code which works. You have lofty claims and idealism's.

Sure. @takluyver said a couple of times that core members of Ipython wanted to explore alternatives to the way they are writing the front-end because they are tired of fixing one issue and in the process, introduce another issue, particularly in relation to CSS. That is why I said "If you keep solving layout issues with Javascript when it is not necessary, the same problem will arise (with or without phosphor)."

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?

What do you mean? Did you already use the Ipython notebook in phosphor?

Yes. @ellisonbg has seen it.

That's true, but maybe because you usually don't need a library to deal with layout even for IDEs in the browser (e.g. codiad, cloud9.)

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:
cloud9

@rsmith31415

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 position: absolute;, height, width, innerWidth, innerHeight, etc. By the way, that detail is important because when you declare your styles, the browser caches the style sheet. On the contrary, inline styles always need to be downloaded. It is also important because it is more likely to generate a reflow by using inline styles.

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.

Phosphor layouts compute the x, y, width, and height (in pixels) of each widget entirely in Javascript and write those values directly to the style object. The browser does not compute them. The only part of the CSS engine which is involved with this is the cascade (i.e. the style recomputation in the timeline), which is a trivial computation because the inline style object has the highest precedence (aside from !important).

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.

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 position: absolute;. In that case, the modal component of Jquery is also high performance and everything that uses position: absolute; is suddenly "high performance". Furthermore, as I explain in the other issue, that browser feature is supposed to improve performance when you have a small number of children, but in our case, we would have a large number of nodes in each panel. Therefore, this is not even the beginning of a solution. However, I agree that it doesn't make performance worse.

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.

As I said, you're comparing a three year old web service with a demo. That's hardly a fair comparison.

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?

Yes, but no one said we intended to do a tabbed/paneled interface without Javascript (the difference lies between 100% and 5% of Javascript).

So then find or write a library which does it with 5% Javascript and has the same performance and flexibility. Otherwise, you're just wasting people's time and energy with this nonsense. I have code which works. You have lofty claims and idealism's.

Sure. @takluyver said a couple of times that core members of Ipython wanted to explore alternatives to the way they are writing the front-end because they are tired of fixing one issue and in the process, introduce another issue, particularly in relation to CSS. That is why I said "If you keep solving layout issues with Javascript when it is not necessary, the same problem will arise (with or without phosphor)."

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?

What do you mean? Did you already use the Ipython notebook in phosphor?

Yes. @ellisonbg has seen it.

That's true, but maybe because you usually don't need a library to deal with layout even for IDEs in the browser (e.g. codiad, cloud9.)

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:
cloud9

@rsmith31415

This comment has been minimized.

Show comment
Hide comment
@rsmith31415

rsmith31415 Apr 3, 2015

Contributor

@sccolbert

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.

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.

Phosphor layouts compute the x, y, width, and height (in pixels) of each widget entirely in Javascript and write those values directly to the style object. The browser does not compute them. The only part of the CSS engine which is involved with this is the cascade (i.e. the style recomputation in the timeline), which is a trivial computation because the inline style object has the highest precedence (aside from !important).

You really need to read the W3C specifications. Javascript allows you to change the style object of an element but that style object is in no way different than style objects created using a simple style sheet. Every style object is an instance of CSSStyleDeclaration (in the CSSOM) which in turn represents a CSS block. Therefore, the browser needs to compute it in the same manner as when computing style sheets. You're confusing the Javascript that is used to manipulate DOM properties and the CSSOM (which exposes a CSS API) that actually does the work.

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.

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.

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.

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.

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.

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 position: absolute;). By the way, I'm not saying that position: absolute; produces worse performance than not using it, but the improvements are not so significant in this particular situation.

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.

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.

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.

Sure. A random example.

So then find or write a library which does it with 5% Javascript and has the same performance and flexibility. Otherwise, you're just wasting people's time and energy with this nonsense. I have code which works. You have lofty claims and idealism's.

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.

Yes. @ellisonbg has seen it.

Excellent. Why don't you make a pull request?

Your owns 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:

That statement is correct only if "large in-house library" is equivalent to "we write code according to our requirements".

Contributor

rsmith31415 commented Apr 3, 2015

@sccolbert

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.

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.

Phosphor layouts compute the x, y, width, and height (in pixels) of each widget entirely in Javascript and write those values directly to the style object. The browser does not compute them. The only part of the CSS engine which is involved with this is the cascade (i.e. the style recomputation in the timeline), which is a trivial computation because the inline style object has the highest precedence (aside from !important).

You really need to read the W3C specifications. Javascript allows you to change the style object of an element but that style object is in no way different than style objects created using a simple style sheet. Every style object is an instance of CSSStyleDeclaration (in the CSSOM) which in turn represents a CSS block. Therefore, the browser needs to compute it in the same manner as when computing style sheets. You're confusing the Javascript that is used to manipulate DOM properties and the CSSOM (which exposes a CSS API) that actually does the work.

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.

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.

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.

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.

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.

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 position: absolute;). By the way, I'm not saying that position: absolute; produces worse performance than not using it, but the improvements are not so significant in this particular situation.

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.

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.

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.

Sure. A random example.

So then find or write a library which does it with 5% Javascript and has the same performance and flexibility. Otherwise, you're just wasting people's time and energy with this nonsense. I have code which works. You have lofty claims and idealism's.

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.

Yes. @ellisonbg has seen it.

Excellent. Why don't you make a pull request?

Your owns 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:

That statement is correct only if "large in-house library" is equivalent to "we write code according to our requirements".

@sccolbert

This comment has been minimized.

Show comment
Hide comment
@sccolbert

sccolbert Apr 3, 2015

@rsmith31415

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.

@rsmith31415

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.

@fperez

This comment has been minimized.

Show comment
Hide comment
@fperez

fperez Apr 3, 2015

Member

Hi folks,

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:

  • we have been working with the folks at Bloomberg for many years (before they were there), since @sccolbert's days at Enthought and @jasongrout as one of the main contributors to Sage: that knowledge is important, as it helps us know that they have a serious, long-term commitment to the well-being of IPython/Jupyter and the open source ecosystem they operate in.
  • the 'bus factor one' issue is indeed one we take seriously. It is mitigated by several factors: we are building a shared knowledge of the tool, its scope is limited, and their commitment to it is serious enough that hopefully before long its team will grow.
  • @sccolbert, @jasongrout and Sylvain have skin in this game: if we look at the IPython commit logs for the last year or our dev meetings on YouTube, @jasongrout and Sylvain do appear prominently as very active participants in the last year+. They have been critical to lots of our recent thinking, and we know their interest in this runs deep and is serious. They are first-class members of our core dev team, having gotten there thanks to their long-term record of contributions to the project and related ones (like Sage and others).
  • we need what Phosphor does well, and it plays well with complementary tools, so we aren't imposing this solution on the world. We're only choosing it for the layout of the application itself, the outer shell. Since that's our app, that's one place where we do get to dictate the choices.
  • at our dev meetings, we took lots of time to dive deeply into the tool, and we have, as a team, made a concerted decision to move forward for now. We aren't ignoring the existing issues, but we feel the benefits outweigh the costs. We always have to take some risks, and we are also willing to and capable of re-evaluating our choices if later down the road they prove problematic. But at some point, we need to commit to a choice and try to follow it, making any improvements we can along the way.

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.

Thanks everyone!

Member

fperez commented Apr 3, 2015

Hi folks,

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:

  • we have been working with the folks at Bloomberg for many years (before they were there), since @sccolbert's days at Enthought and @jasongrout as one of the main contributors to Sage: that knowledge is important, as it helps us know that they have a serious, long-term commitment to the well-being of IPython/Jupyter and the open source ecosystem they operate in.
  • the 'bus factor one' issue is indeed one we take seriously. It is mitigated by several factors: we are building a shared knowledge of the tool, its scope is limited, and their commitment to it is serious enough that hopefully before long its team will grow.
  • @sccolbert, @jasongrout and Sylvain have skin in this game: if we look at the IPython commit logs for the last year or our dev meetings on YouTube, @jasongrout and Sylvain do appear prominently as very active participants in the last year+. They have been critical to lots of our recent thinking, and we know their interest in this runs deep and is serious. They are first-class members of our core dev team, having gotten there thanks to their long-term record of contributions to the project and related ones (like Sage and others).
  • we need what Phosphor does well, and it plays well with complementary tools, so we aren't imposing this solution on the world. We're only choosing it for the layout of the application itself, the outer shell. Since that's our app, that's one place where we do get to dictate the choices.
  • at our dev meetings, we took lots of time to dive deeply into the tool, and we have, as a team, made a concerted decision to move forward for now. We aren't ignoring the existing issues, but we feel the benefits outweigh the costs. We always have to take some risks, and we are also willing to and capable of re-evaluating our choices if later down the road they prove problematic. But at some point, we need to commit to a choice and try to follow it, making any improvements we can along the way.

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.

Thanks everyone!

@fperez fperez closed this Apr 3, 2015

@rsmith31415

This comment has been minimized.

Show comment
Hide comment
@rsmith31415

rsmith31415 Apr 3, 2015

Contributor

@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.

Contributor

rsmith31415 commented Apr 3, 2015

@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.

@fperez

This comment has been minimized.

Show comment
Hide comment
@fperez

fperez Apr 3, 2015

Member

@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 ;)

Member

fperez commented Apr 3, 2015

@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 ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment