PLIP: Approve use of React in core, deprecate backbone

vangheem commented 8 years ago

Proposer : vangheem

Seconder : ?

Abstract

I propose we allow using React in core and deprecate the use of Backbone JS.

Backbone is used currently to manage complex patterns; however, it has not done a great job and we have jQuery mixed in all over the place.

Being able to use React will provide a much better developer experience and make it easier to manage complex patterns like the structure.

Motivation

Currently in core JS, some of our patterns are overly complex. Where we have complex patterns, we have used backbone JS. Backbone was never explicitly authorized for use in core but it was used and has been used because it is already there.

Assumptions

Proposal & Implementation

upgrade mockup react to latest
the only pattern I propose to migrate to using react right now is resource registries. It can stand as an example of how to do it.
this proposal is only use react without jsx or anything else in the potential react toolchain
Current patterns that use backbone
filemanager
resourceregistry
structure
thememapper
Deliverables
a PR with the upgraded react and migrated resource registries pattern
Risks
should we use react-lite?
does it add yet another complex thing in our JS story?
who wants to fight about which framework to use?

thet commented 8 years ago

Not sure if I would like the move to React. I don't have much experience with it but code I've seen isn't easy to understand and I have heard/read controversial things about it. Have you heard about vue.js? Looks like it's an lightweight but still flexible and more performant alternative to what is hyped otherwhere at the moment. Here is an interesting read about comparison with other frameworks, e.g. React: http://vuejs.org/guide/comparison.html#React

vangheem commented 8 years ago

I knew this would start a fight :).

Thing is, we already have a soft dependency on react and it's popular(has major companies behind it). I really don't want to add another potential library. Angular won't work because it require whole-sale buy-in to work and won't really work along with our patterns.

vue.js looks good but everything is a trade-off. I'd prefer to stick with the more popular libraries...

ebrehault commented 8 years ago

+1 because:

Backbone is not a key element of the core JS architecture, and I haven't the feeling it is widely used by add-on developers,
React is a small framework, and it is not exclusive (Angular for instance is much more exclusive, it is difficult to use it in parallel of other approaches), so it is not like if we make here an important strategic choice (we just add React and we use it for some of our components, people are free to use it if they want; so that's basically what we did with Backbone at the time).

Regarding react-lite: of course it sounds better to use a smaller lib than a bigger one, but:

I am not sure react-lite is as actively maintained as React itself,
when working with it, we will find React doc, React code samples, etc., and we will always have to make sure it is supported by react-lite. So I would prefer React iself.

Regarding the framework fight:

it is always wiser to remain mainstream. It would be very dangerous to pick anything which is not widely used, actively maintained, fully documented, and with many many answers in Stackoverflow,
there are only two mainstream frameworks at the moment, Angular and React. I like Angular and I use it a lot, but I do not think it is a good match for our needs,
as I just said, it is not a huge strategic choice that will impact our entire JS story, we would just replace an old dependency (backbone) with a younger one.

thet commented 8 years ago

Sure, a framework fight is obvious, isn't it? ;)

However, I want to concrete one of my main concerns about readability - I hope I don't start a miles long discussion about boring frameworks.

Hello world in React without JSX:

"use strict";

var HelloMessage = React.createClass({
  displayName: "HelloMessage",

  render: function render() {
    return React.createElement(
      "div",
      null,
      "Hello ",
      this.props.name
    );
  }
});

ReactDOM.render(React.createElement(HelloMessage, { name: "John" }), mountNode);

Hello world in vue:

<div id="demo">
  <p>{{message}}</p>
  <input v-model="message">
</div>

var demo = new Vue({
  el: '#demo',
  data: {
    message: 'Hello Vue.js!'
  }
})

The React example much more unreadable. The only (big) benefit of React is, that the community is larger.

thet commented 8 years ago

I don't want to endorse vue too much, although I thinks it's very interesting. But I don't know where they are heading. Github stars, watches and graphs are not bad even compared to the other frameworks including ember, but the vast majority of commits come from one single person.

hvelarde commented 8 years ago

@rodfersou FYI

tisto commented 8 years ago

I pretty much agree with everything @ebrehault wrote. I think moving from Backbone to React would be a huge win in general. Though, I think we have to take into consideration that:

a) choosing React also means buying into a larger ecosystem of tools (if we use React we might want to use JSX, Webpack, Redux, React Hot Loader, etc.). We can of course limit its usage to the resource registry and decide we are not using anything else from the React toolchain, but I'm not sure that would really work out.

b) we should try to make sure our decision aligns with our long term goals (choosing React now and then moving to another framework at a later point would be pretty confusing and potentially waste a lot of energy).

rodfersou commented 8 years ago

I think everyone that already worked with backbone has the same feeling: some day I need to change it to another framework..

I like this idea in general, I tried to study something new, and the answer from my research was http://mithril.js.org/

But I didn't took a good look into Vuejs, that one is new to me.

Anyway, I appreciate this idea to look for something new, and I look forward in this thread to know what framework should I learn now.

vangheem commented 8 years ago

"I look forward in this thread to know what framework should I learn now" -- this is so depressing.

rodfersou commented 8 years ago

@vangheem why? I just don't want to waste my time and strength studding something the community will not use in core.

vangheem commented 8 years ago

I understand, I just hate the position we're put into where your comment is completely reasonable.

We've been talking about this for years now...

rodfersou commented 8 years ago

@vangheem anyway, could you please take a look into mithril.js and write your feelings about it?

hvelarde commented 8 years ago

@vangheem for me, the motivation of this PLIP is not clear enough and changing a JavaScript framework sounds as something scary: complexity means higher entropy, and higher entropy means we will need more energy to maintain things working. can we just stop for a moment, take a breath of fresh air and think?

please answer the following questions for me to help you think about the current status of this in Plone: why some of our patterns are overly complex? do we need this complexity? can we reduce the level of complexity somehow? have you already analyzed simpler/smaller/faster other alternatives like Mithril and/or Vue.js for this job?

BTW, what's exactly the job we are trying to accomplish by changing the framework? do we just want JavaScript for the widgets or something else? I think that's exactly what @tisto is talking about.

vangheem commented 8 years ago

Overly complex was a bad way of putting it. I should probably say that backbone doesn't manage complexity as well as react does.

bloodbare commented 8 years ago

I fully agree with you guys, my two cents to the framework "fight":

1rst assumption - we are using patternslib/mockup to provide js functionality on the UI 2nd assumption - there is going to be initiatives that will try to create RESTAPI based full JS frontend 3rd assumption - nowadays js world is changing fast, there is a big community of people writing tons of cool pieces and there is some big communities on some frameworks (React/Angular).... 4rd assumption - all actual development on the web world is oriented to be web component behavior and our idea of patterns fits on the web component behavior 5rd assumption - Big players are developing their solutions with "compatibility"

So

I've always thought that maintaining our own framework is not good for complexity, maintanability, integration,... Some said to me that choosing one framework may not be good for people using another one and that mockup/patternslib is so small that does not bother. Its clear that there is not going to be a good solution, maybe I want to do it with polymer, somebody else in react and somebody else in patternslib, Vue or mithril or maybe also angular[1,2]. Its a never ending question because all are good in different aspects.

I've used most of them in different projects with enought deepth to see the goods and bads, and here is my aproach:

Use simple framework for simple patterns, imagine that you want a pattern that changes the color, use something simple like patternslib or polymer (I love this last one for simple webcomponents and its standard, but I understand that we have a good documentation and lot of code using patternslib, so ok)
Use react/angular2 for complex web components, we have some pretty complex elements like structure, resource registry, .... I personally prefer angular2 because it may help to create a model of interaction with RESTAPI and its one of my interests right now, but we can use react that is only 26k, and if we never end creating a UI front on js we may use angular2...

I would say that this discussion is one of the focused discussion on Barcelona Sprint, how to draw an easy, not hard to move (or try to reuse as much as possible) picture of how a js front can be build on top of plone.

About the complexity, I don't know how already saw how structure widget works, or resource registry... complexity is there on complex widgets, no matter the framework.

vangheem commented 8 years ago

mithril.js looks good. vue.js is also nice but has the advantage of having built-in templating.

I know people might not like me saying this but.... It's more important to choose a framework that has support and a large community around it than it is to choose the absolute, most technically interesting solution.

vangheem commented 8 years ago

React isn't perfect, but it's good for the use-case we have and we need something to evolve with. Other frameworks are very good as well but it'll never end if we compare every framework.

Backbone is not where we want to be.

Keep in mind, we already ship with react, mockup has a soft dependency on it for it's docs.

rodfersou commented 8 years ago

:+1: for me it is ok to try and learn reactjs

hvelarde commented 8 years ago

@vangheem it's a pity you don't want to play the game because I think it will help you on putting your ideas in order; sometimes seems to me you need to work less and think more ;-)

+1 on @bloodbare idea on using different frameworks for different levels of complexity; I'll vote then for React and Mithril, because I don't want to write TypeScript.

worth reading: https://auth0.com/blog/2016/01/07/more-benchmarks-virtual-dom-vs-angular-12-vs-mithril-js-vs-the-rest/

rodfersou commented 8 years ago

for me to use different frameworks in the same CMS is the worse stuff we should do.

then we need to learn every framework in the earth while we have just one CMS?

and the size of the final JS? not everyone in the world has a good internet connection, and mobile devices will suffer to open a plone site.

rodfersou commented 8 years ago

@hvelarde about TypeScript, you don't need to write anything with typescript.. Angular is written in it, but you can use es6 or coffeescript or anything with Angular (I had the same doubt before).

thet commented 8 years ago

The article @hvelarde mentioned above gives very good results for React.

Having a good and established JS framework at hand, which doesn't put too much payload to the whole stack is a good thing. I try to list the most important criterias which should be considered for choosing a framework:

maintenance / industry support / community size / future proofness
documentation
features
performance
library size
plays well with other libraries
easiness of use / code readability

Looks like React is very good at each criteria except maybe the last one. If those people who have React experience don't feel it's a PITA (like it looks like when seeing the hello world example), I'm OK with going with it.

ebrehault commented 8 years ago

I am not sure the PLIP objective is to "choose" a JS framework.

At the moment, we do have Backbone.js, but we never said: "Backbone is the Plone JS framework, and everybody have to use it", and we never built any specific backend endpoints to serve a generic and ready-to-use Backbone infrastructure.

The actual current status is just that:

Backbone is one of the dependencies in our core bundles,
we do use it is some Mockup widgets (but not all),
people can use it if they want in their own dev (just like they can use requireJS or jQuery or ACE which are also provided by default in Plone),
people can also use Angular, or vanilla JS, or anything (they just need to add the lib in a bundle), nothing in Plone is Backbone-specific in anyway.

The PLIP objective is to remove Backbone, and use React. So zero impact (but for core-developers maintaining Mockup of course).

Note: if, at some point, Plone needs to provide some JS framework-specific REST endpoints, or change in a specific way its bundling mechanism, or anything else in the front story which would make a given framework the official Plone framework, then yes, we will need to carefully choose this framework, as people will probably have to learn about it, it will have to be documented, it will have an impact on add-ons development, etc.

It might happen someday, but we are not there.

thet commented 8 years ago

The patterns functionality, which is eventually implemented with the JS framework in question, is exposed to the front end. It also gives us a tool, which we can immediately use for custom development, because it's just there. I think the Framework question has some relevance.

But if we don't endorse it as the "official JS framework supported by Plone", it does not have much impact - I agree @ebrehault

hvelarde commented 8 years ago

@ebrehault thank you for the explanation, that's what I needed.

tisto commented 8 years ago

Again, I fully agree with @ebrehault, we should narrow the scope of the discussion to replacing backbone with react, not about making a final decision regarding a framework.

@vangheem could you amend your PLIP to make that clear? It would also be nice if you could be a bit more specific about the current use of backbone in core (a list of patterns). Do you plan to use React with JSX or to use anything else from the React toolchain?

vangheem commented 8 years ago

@tisto Yes, thank you. I've update the description.

My proposal would just be to use react without anything other parts of the toolchain as well as no jsx.

davisagli commented 8 years ago

I like both Backbone and React, but the proposal lacks sufficient detail for me to have a clear opinion. React is pretty focused on rendering views using components, whereas Backbone takes care of routing and managing collections of models, but is pretty agnostic about how views get rendered. Are we not using those features of Backbone? If we are, how do you propose to replace them? We might need an actual implementation to use as a straw man and see if/how it makes things clearer.

vangheem commented 8 years ago

We don't use routing; however, we do use collections and models in the structure pattern; however, they are unnecessary constructs and can be simplified there.

bloodbare commented 8 years ago

If my memory does not fail we were using Backbone router in modal to automatic open a modal or show a folder depending on the url we push:

https://github.com/plone/mockup/blob/767dc7d9eaf216392277052f755f1e4c9e1e26a0/mockup/patterns/modal/pattern.js#L505

datakurre commented 8 years ago

:+1: and :+1: for official react in core (react-lite should be drop-in replacement for those, who want to optimize)

FWIW, I've enjoyed using react + redux for complex widgets (its data flow was nice fit in (de)serializing data for input fields).

ebrehault commented 8 years ago

The PLIP has been approved. See https://community.plone.org/t/framework-team-meeting-minutes-2016-04-12/1943

rodfersou commented 8 years ago

Nice! can we define now what set of tools to use together with reactjs? I mean.. what task runner, what module style (requirejs?!) and what test framework?

There are some generators of yeoman (same idea of bob templates) with a set of tools pre-selected:

I think it is faster and painless to use something that there are a community around using than to create our own set of tools.

rodfersou commented 8 years ago

A friend of mine ( @renancouto ) recommended this one https://voice.kadira.io/say-hello-to-react-cdk-97cff692e798#.kf0vo39px https://voice.kadira.io/introducing-react-storybook-ec27f28de1e2#.9j9zlo1p0

rnixx commented 8 years ago

Beside that this PLIP now has been approved...

I want to hook up the following:

"I look forward in this thread to know what framework should I learn now" -- this is so depressing.

and

We've been talking about this for years now...

Whenever the Plone community committed itself to a specific JS framework in the past it turned out that it backed the wrong horse. The only exception is jQuery (funnily there have been strong concerns especially against jQuery).

This might be more the volatile nature of JS frameworks than the skill to judge the technical questions of a specific framework, and I doubt this really gets better in the near future.

My personal conclusion from this evolution is that I avoid JS frameworks wherever possible (except jQuery because it's in virtually everywhere).

This does not mean that it makes no sense to have/use some framework in a product, but I'd reduce dependencies to a minimum.

In my opinion for Plone this could be jQuery, require and maybe react which gets delivered by default, but in a way that nobody is forced to use anything of it and everyone may load whatever she likes (if this makes sense referring stable applications is another question).