Deciding on a standard front-end framework to build animations

[Rishav159]

I think we should decide on a standard front end framework for the purpose of creating animations. I don't have a lot of experience in this field and thus want suggestions regarding this. I have tried two.js in the Breadth First Search visualizations in Chapter 3. Thanks in advance.

[Ghost---Shadow]

I explored a few graphics libraries a while back, the only other alternative was D3JS. I did not pick it because it is mostly for charts. two.js is versatile enough to do anything while being simple enough to pick up.

If in later chapters 3D animations are needed, three.js can be used.

[redblobgames]

Con: D3.js does not have the output-independence that two.js has (svg or canvas or webgl) Con: D3.js's enter/exit pattern isn't that useful to us, and may get in the way Con: D3.js is harder to learn than two.js (in part because two.js limits what you have access to) Pro: D3.js has good support for transitions, mouseovers, other interaction effects Pro: D3.js is much more widely used than two.js (larger community, more contributors will already know it) Pro: Some chapters do have charts with axes etc. and D3.js makes those easier

I think we should stick to two.js for now but be open to using d3.js, or maybe we can decide chapter by chapter.

[Jeet1994]

@redblobgames Let's not forget the huge community support and documentation that D3.js has.

[bhavya9107]

Can also write up using p5.js it has support for various interactions and great good reference material

[Ghost---Shadow]

@bhavya9107 Just use processing.js. Its mature enough, in my opinion. two.js is very similar to processing's setup - loop - draw - update workflow.

[redblobgames]

@bhavya9107 p5.js seems like a fine library. Right now we are using two.js but I think having a decision per chapter instead of trying to pick one library will allow us to make more different types of visualizations (e.g. 3d in three.js, charts in highchart, etc.), and also accept contributions from more people.

As this is aima-javascript, I would prefer us to use javascript directly instead of using other languages that are translated into javascript (e.g. processing.js or coffeescript or haxe or typescript or scala.js or clojurescript or elm or c++ via emscripten), but I'd like to hear other opinions on whether we should open things up to allow all compile-to-javascript languages.

[alireza-a]

@redblobgames Making decisions per chapter and opening to more libraries is a welcome change. However, this introduces a cost for moving between chapters. Maybe we should make a list of accepted libraries and later make justifications for using something outside this list.

but I'd like to hear other opinions on whether we should open things up to allow all compile-to-javascript languages.

Using TypeScript would allow for better code refactorization while keeping the code base close to JavaScript. Also introducing types makes it easier to read someone else's code. However, this again introduces a cost for moving between chapters.

[redblobgames]

I've moved two.js from being global to be per-chapter. Yes, it adds a cost to move between chapters, but I think most of the time will be on implementing the AI algorithms (which don't depend on visualization) and then on experimentation to learn what visualizations work (throwing away most of the work). My hope is that the amount of visualization code we keep will be small.

[nervgh]

Hello!

There1, there2 and there3 I and @redblobgames have mentioned libraries/frameworks like jQuery and Vue. The key points which I'll want to discuss here are a) the consistency and b) the reducing dependencies.

1. My first thought is "Do we really need jQuery?" I mean we use ECMAScript 2015 which support only edge browsers. For example, each time when we write class A extends ... B we break compatibility with not so old browsers like IE11. I think we don't need jQuery actually. There are not such many benefits from jQuery today as at the past. Today's browsers' DOM API is very expressive. We can use it directly without low-level dependencies like jQuery. For instance:

   // instead
   $(document).ready(function() {
   });

   just move the scripts at the bottom of a document

   <head>
     <!-- some meta and styles here -->
   </head>
   <body>
     <p>Page<p>
     <!-- place scripts here-->
     <script src="script.js">
   </body>

   I propose reduce jQuery for chapters where it is reasonable.

2. My second thought is "declarative over imperative/write less do more". Each time when we use jQuery we are forced to write the imperative code for synchronization the model with the UI. We are forced to write more and more code using this approach and the supporting of the code is becoming harder and harder. This can be compared with the exponential growth of complexity. But today there are data-driven tools like Vue. It looks like a template where we load our data. When we change our data (model) it causes UI changes. As result it is simpler (less) to write, to read and to support. This can be compared with the linear growth (in my opinion) if you prefer analogies :smile_cat:

What do you think about it?

[redblobgames]

@nervgh I agree about moving the scripts to the bottom. We have changed some chapters to do this but not yet all of them. (Most chapters, nobody is working on.) I think Bootstrap requires jQuery so we may still end up including it. :(

There isn't a lot of jQuery (117 lines out of 6124). Most of the visualization UI is not done with jQuery, but instead done with a visualization library (Two.js or D3.js). And of those, the visualizations with Two.js are using jQuery, and the visualizations with D3.js is not using jQuery. And even the places that are using jQuery are using very few parts of jQuery. So it may not be too hard to remove it.

For the declarative approaches, React and Vue are nice when working with the DOM. They become trickier for things that aren't directly functional mappings to the DOM. Two areas in particular:

1. D3.js has direct support for multi-stage transitions. I translated ch 2 from two.js to d3.js and found that transitions made a lot of the animation simpler. D3 directly supports the types of transitions that are commonly used in visualization (not only positions but also things like colors and transforms -- for example, between two CIE color space colors), and it supports non-CSS transitions. Even though CSS transitions are great, they're not universally supported across browsers for SVG :-( so we need a separate mechanism for SVG transitions (which D3 has). You can do this in React and Vue with a third party library like Tween.
2. Non-SVG. Two.js and D3.js support both SVG and Canvas. Two.js makes the transition easier; D3 makes it more explicit. We have switched some visualizations from SVG to Canvas. I've seen some React+Canvas plugins but I haven't seen Vue+Canvas examples that make good use of Vue. Do you have any recommendations?

I don't know what you mean by “exponential growth” unless you are meaning this in a figurative sense. There isn't anything “exponential” in this project by using D3 or Two.js instead of React or Vue. D3 supports UI synchronization with the "enter/exit pattern" and Two.js supports it by by keeping a scene graph tree (not exactly the same as the virtual dom used by React and Vue). These are all “linear growth” except the constants are a little higher in the imperative styles (because they support doing more things than the declarative style does).

I do like the declarative model quite a lot (I used Vue for this page and for some other projects), and if someone working on the majority of a chapter wants to use Vue, that would be cool. Most of the chapters haven't been started yet, so if you're interested in implementing a significant part of a chapter with Vue, that'd be great, and it'd serve as an showcase of how to use a declarative framework for these types of algorithm visualizations.

[Ghost---Shadow]

I was going through React Pong. It looks like a lot of effort for something so simple. React Canvas is justified if the project is large and there is a substantial amount of logical complexity. However, here we are mostly dealing with several smaller games instead of one large game.

Another reason, I picked two.js was because I was used to thinking with the OpenGL pipeline and so it made sense to me without any additional effort. I should have explored d3.js. I am quite surprised how good d3.js turned out to be.

[redblobgames]

@Ghost---Shadow I agree, we're building hundreds of small things (with a little bit of sharing) instead of one big thing, and some of the frameworks (React, Angular, Ember, etc.) are designed for making a big system. I think one reason d3 is a good fit for us is that it is most commonly used with hundreds of small things (https://bl.ocks.org/). Plus, it's designed for visualization instead of “web apps”. I think Two.js is much better than D3 at hiding SVG vs Canvas vs WebGL, but it's worse at animation and interaction than D3. Pixi is also interesting for hiding Canvas vs WebGL.

I noticed in one project that WebGL can be problematic when you have many separate visualizations on the page. There's a limit on how many contexts you can have, and it varies by system, so I had a page that worked fine on my desktop but only drew the first four diagrams on mobile :-(

[nervgh]

@redblobgames

I think Bootstrap requires jQuery so we may still end up including it.

We need jQuery only if we would use some Bootstrap's js-components which require jQuery. In other words, we don't need jQuery when we use Bootstrap's stylesheets only.

For the declarative approaches, React and Vue are nice when working with the DOM. They become trickier for things that aren't directly functional mappings to the DOM

+1

I've seen some React+Canvas plugins but I haven't seen Vue+Canvas examples that make good use of Vue. Do you have any recommendations?

I haven't seen that. Google says that there is vue-canvas but I don't think that it would be suitable for us.

Most of the chapters haven't been started yet, so if you're interested in implementing a significant part of a chapter with Vue, that'd be great, and it'd serve as an showcase of how to use a declarative framework for these types of algorithm visualizations.

Thank you! I will keep that in my mind =)

[redblobgames]

I'm closing this bug from 2017. The priority in 2018 was not uniformity across the codebase, but instead a focus on the end user. In 2019 uniformity across the codebase will again not be a priority. We can reopen this in 2020 if the maintainer decides to change this.