[Templating] replace Blaze with React.

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

[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

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