[Templating] replace Blaze with React.

[santisiri]

This is a massive undertaking, but I'll just post it here. We currently implemented Sovereign using Meteor-exclusive Blaze (which does a very good job) but in order to increase collaboration with other devs out there, replacing this with React might be a desirable migration.

Here's a comparison between Blaze, React & Angular: https://guide.meteor.com/v1.3/ui-ux.html#view-layers

Basic documentation on Meteor & React: https://guide.meteor.com/v1.3/react.html

React vs. Blaze: https://themeteorchef.com/blog/react-vs-blaze/

A rough visual of parts affected by migration:

/imports
|-- startup
|  |-- client
|  |  |-- routes.js
|-- ui
|  |-- templates
|     |-- components/*
|     |-- layout/*
|     |-- widgets/*

Work is being done on prj-9-blaze-to-react branch

[utanapishtim]

+1

[utanapishtim]

I think this will also open up contributions from a large community of talented and interested folks.

[matdurand]

Hi guys. Great project!

You should check this as a couple of steps to move to React and also replace IronRouter with FlowRouter. https://www.discovermeteor.com/category/blaze-to-react/

Also, the guys from kadira released a application architecture named Mantra (https://github.com/kadirahq/mantra) which use React as a view layer. This may be overkill to implement this since you already started.

And do plan on releasing a mobile app on cordova or just a mobile web site ? If you do, you should check Framework7 (http://framework7.io), which really add a native feeling to the application. Even if you don't, framework7 still provides a lot of components that can be used standalone. It's not compatible with bootstrap though.

[santisiri]

@matdurand awesome feedback!

Regarding migrating to FlowRouter, absolutely. I will create a new issue for this specifically. It has been recommended to us before.

Wasn't aware of Mantra. We do plan to make a native mobile app using Cordova in the near future. Didn't know Framework7 (we don't use bootstrap).

Excellent recommendations. Thanks again!

[matdurand]

Just a heads-up though, this came out yesterday. The main maintainer for FlowRouter is apparently leaving meteor. Don't know what this means for the future and for Kadira. https://voice.kadira.io/its-time-thank-you-bye-meteor-115dd649a8#.8l9ul84n3

[santisiri]

So I've been looking into react and I will incorporate it into the codebase of Sovereign very soon. I will start building components using react and making small migrations of existing ones while moving up the chain that connects them.

[brylie]

Just my two cents, but the original mission of Meteor, and hence Blaze, was to make the developer experience simple and humane. Around the beginning of 2015, Meteor literally lost its mission (the mission page on the website was removed). Around the same time, and since, there was a big push for react from many prominent voices in the Meteor community. Some of these influencers have since largely stepped away from Meteor, leaving the community landscape transformed, missionless, and with questions about the lifespan of crucial infrastructure and components.

I for one was drawn to Meteor for its simplicity and humanism. In my opinion, React makes projects less accessible to a wide developer community, such as people just learning to code. JSX syntax is difficult to read and makes developers switch modes of thinking frequently, incresing cognitive load.

There are other prominent frontend frameworks to consider, such as Vue.js, which offer much cleaner looking code and an easier learning curve. Additionally, some frontend frameworks, such as Aurelia and Polymer, are designed with full standards compliance (e.g. Web Components) baked in from the start.

Please take into account these broader human needs of simplicity, readability, and easy learning curve when deciding on the next phase frontend framework for Sovereign.

Respectfully, Brylie

[domi41]

Thanks @brylie for this food for thoughts ; and for Vue.js, which definitely deserves the attention.

On one hand, there's the pragmatism of the actual skill set of the main sovereign developers ; on the other hand, there's the KISS principle.

[brylie]

On one hand, there's the pragmatism of the actual skill set of the main sovereign developers ; on the other hand, there's the KISS principle.

Pragmatism is a good heuristic but may be a poor compass - at best leading towards a local maxima. Pragmatism needs a stable framework of explicit values, clarity of vision, and a concrete mission.

It might not immediately seem obvious how a choice of frontend component model might have an impact on mission, vision, or values of this project. However, a democratic system, including the underlying sourcecode, needs to be inclusive and accessible in order to be widely effective.

As a practical recommendation, I offer that we consider Aurelia, for the following reasons:

• it has a simple design and explicit focus on developer ergonomics
• easy to learn
• it is performant
• batteries included
• it is standards-based, embracing the Web Platform

[domi41]

There's actually a pretty good case for Aurelia all over the web. Thanks for this, I will definitely give it a try ! This makes me even more convinced that a good feature suite in Gherkin is the best thing I can do right now.

What about the sunk costs, though ?

[brylie]

What about the sunk costs, though ?

That is a big question :stuck_out_tongue_closed_eyes:

This makes me even more convinced that a good feature suite in Gherkin is the best thing I can do right now.

:+1:

[santisiri]

Very interesting thoughts guys.

@brylie I actually agree with your reasoning a lot.

Meteor was a decision aimed at guaranteeing that code readability was simple, accessible for most and at the same time it's a platform that can eventually generate an app across multiple platforms. I'm actually very glad that you 'get it' so well and even put it in way better words than I can use to describe this decision.

I've been following the latest developments around Meteor and even though it felt like last year that they put focus on Apollo, it seems now that now they're gonna redouble efforts on Meteor itself. Check this interview recently published with a lead dev, it restored my faith in Meteor :)

Regarding react, I think that a significant chunk of the open source community has picked it as the winner in frontend dev for a bunch of different reasons and I think we can gain a lot by engaging that community with our project as well.

Although it might be a bit more complex than Blaze, I think it has a lot of benefits that we should consider in the long term. react-native for instance actually works very well across mobile platforms (it really does the trick of one code to rule them all at certain extent). And the JSX model although weird at the beginning, i think it nails many things by turning the redundancy of using div into properly named components (hence improving readability as a whole). And it makes classes built on react far more reusable (even beyond this project) than components otherwise built on Blaze. In that sense could lead even to spin-off projects with more ease.

A great dev and good friend, @rauchg, shared recently some interesting thoughts on JSX:

The triumph of JSX is making it look like it's "HTML-in-JS", but at the same time providing a powerful abstraction over it.

That said:

I wouldn't go in a radical direction where we change everything nor even do a major refactor.. A major migration is not desired here, we already have a lot of good work done, so we won't have any sunk costs.. but starting with the smallest components and explore from there if it makes sense, could be a reasonable step to take while engaging new devs familiar with react to check out our project. The Meteor community looks to be pushing for react as well too, so I think would be a good way of connecting with that community as well.

[medied]

Great conversation. As someone getting started with React recently, I agree the learning curve is there. Not too steep, but JSX does make React particularly different to pick up.

A major migration is not desired here, we already have a lot of good work done, so we won't have any sunk costs..

Yes, hopefully we won't have to get half-way there to realize that the store is closed (as per the metaphor). The sooner we start experimenting, and engage devs with React experience, the sooner we will know it if React makes sense or not.

To take the first steps in migrating, I've started a project and branch prj-9-blaze-to-react. Anyone is welcome to help there!

[domi41]

Would love to use the feature suite #198 while refactoring to React ; it would make it easier !

Can we merge it in master, and update or maybe rebase the prj-9-blaze-to-react on the new master ?

[domi41]

Found a lib that kind of makes React feel old and bloated : https://github.com/infernojs/inferno

[santisiri]

Everything related to identity is in react.

Everything related to voting is in blaze.