So, I put together the following diagram to cut through some of the back-and-forth, and help people get on the same page with regards to React and Blaze. It should be pretty self-explanatory to experienced devs; and should hopefully clarify a lot of the discussions for folks who are new to Meteor.
I’m currently working on an article with code samples that gives some concrete refactoring pathways for optimizing apps. In the meantime, let’s all think about the bigger picture of what ‘Pure JavaScript’ means, and why that involves both transpiled languages like CoffeeScript, Stylus, and Jade on one end of the spectrum; and hardware optimized solutions like React on the other end.
Yikes, I remember when Google introduced Google Web Toolkit over Java to unify the whole java web programming ecosystem within Java, eliminating HTML, CSS and Javascript. It was the hype back then. I remember taking lots of heat trying to convince my peers that such convergence were doomed and it would prove to be hype.
If you just remove all the arrows, nice charting, though!
Yeah, this diagram is kinda bidirectional. People go from JS and HTML in both directions - either Coffee/Jade or JSX. So it’s better to leave out the arrows.
The arrows made sense for the first 2 columns, i.e. “the stuff on the left gets compiled into the stuff on the right, e.h. .scss into .css”. If you can write a statement like that for all other arrows as well, then it makes sense to have arrows there. Though be aware that if those arrows mean something else - and it seems that they do, because I don’t know that .scss is compiled to .css is compiled to .jss is compiled to .js is true for all web development. So if those arrows mean something else, even if it’s similar, they should not be the same arrows or should not be all connected or whatever. Arrows that keep flowing in one direction usually indicate a transitive relationship. Do not mess with that expectation.
(Feedback, if you were looking for it.)
I’ve actually perceived it as a train of thought where one can consider shifting/interchanging web programming languages. I honestly don’t know how else it would have been better conveyed, though. But I guess you have a valid point. Perhaps a title/legend or some subtext would have helped.
Yeah, I’m specifically looking at writing documentation to fill in the gaps for doing things like converting .css to .jss, and .html to .jsx (ie. sideburns). Maybe some command line utilities and tools, also.
.css - > .jss
For instance, there’s the jss-cli tool, which will convert .css files into .json objects which can be parsed by React.
.html -> .jsx
This is what all the buzz around Sideburns is about. In theory, the refactor is as simple as replacing the .html file extension with .jsx.
.coffee -> .js
Already well documented. As simple as meteor add coffee.
.less -> .css .style -> .css .scss -> .css
Already well documented. As simple as:
