Cirru Editor, Parinfer and Prettier
I’ve saw people recommending Prettier on Twitter many times. Then @jlongster gave a talk on ReactConf, I saw more and more Tweets about it. Then I decided to try it in our project to see how it works in my case. And turned out, it’s great!
I’m not trying to talk bout Prettier itself. Prettier is a JavaScript formatter, to me it’s like a code formatter with great integrations with text editors that formats code on every file saving. That means I don’t have to layout the code by myself. It is a lot of pleasure that the editor does the boring work for me. I just put the letters, and it got formatted with spaces, indentations, and semi-colons. I do hate writing semi-colons and sometimes even writing commas. Now it’s much better.
However a formatter like Prettier is not new for Clojure community. I’m a Clojure fan but hate that ClojureScript does not work with Webpack by the way. For Clojure we have Parinfer which formats Clojure code even when the parentheses do not match. Unmatched parentheses are syntax errors, but Parinfer has a way to infer the AST and generates the missing parentheses or brackets, and to fix indentations by the way.
A purer formatter for Clojure can be FIPP, which is a pretty printer that I can use to format the code, or even generate code. I think Prettier is more like FIPP comparing to Parinfer, since Parinfer is actually doing more work inferring the missing parts.
Also I saw people cheering about Refmt by Jordan, which is a formatter for ReasonML. Prettier was inspired by it. They both have the flexibility of formatting code based on the width of the window. Yeah, it’s cool! I think with FIPP we can achieve that too since FIPP is configured with a width option.
Now, I’m trying to sell Cirru editor, which I made to solve nearly the same problem but in a different way. The interesting part is it responds to window width too. And since the layout engine is in CSS, Cirru Editor got more flexibilities.
The benefit of Prettier is quite obvious. Code is formatted on every saving, so code from every one in the team is consistent. Meanwhile one does not have to care about where to put brackets and spaces that was handled by the text editor, he/she gets more time to focus on the real problems that programmers need to solve. Be productive.
The different aspect of Cirru Editor is it gave up playing with text and introduced the DOM for layout. The structure of S-expression corresponds to a specific layout of the syntax tree. Every operation to the AST is handled with the DOM tree, which is an UI component based on virtual DOM technology. So a team may share a consistent AST among computers, and they can edit the code in whatever layout engine they installed, and submit the AST back to the main repository.
While Cirru Editor is too hard to use today, I believe we are currently moving toward such a direction that we use structured text editors to eliminate problems we have today: syntax variations, arguments on indentations and semi-colons, recreating wheels with different tastes. Just let the computer to handle it.
