Use of Coffeescript in collective package

Hi everyone,

I like to use Coffeescript because it gives me many syntax sugar, and remembers how I program in Python.

So I would like to use it in some of our community packages, and I need to know what do you think about it.

CoffeeScript is a little language that compiles into JavaScript. Underneath that awkward Java-esque patina, JavaScript has always had a gorgeous heart. CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way.

The golden rule of CoffeeScript is: "It's just JavaScript". The code compiles one-to-one into the equivalent JS, and there is no interpretation at runtime. You can use any existing JavaScript library seamlessly from CoffeeScript (and vice-versa). The compiled output is readable and pretty-printed, will work in every JavaScript runtime, and tends to run as fast or faster than the equivalent handwritten JavaScript.

IMO, by adding just another layer to the development stack we are making harder for people to contribute to the code.

I'm -1 on this.

I understand your concern about "adding a new stack", and I feel the same with many of plone components that we deal with every day..

But, in this case I still think it is a good idea because Javascript scare a lot of people in our community, and Coffeescript will be something a LOT close to the mindset we have with Python, what will enable more people in our community to start contributing with our projects.

I'm also -1. If you want to help people who are scared, give them better information about what we already have; don't add something new.

Please people, keep open mind, and try to at least read about this technology first.

If they are your packages, use whatever you want.

Maybe babel or typescript are better options these days anyways though?

Use what you want. People who can write JavaScript, can write coffescript. I know @ramon loves coffeescript(however, he may have moved on to typescript now).

No one in the community should be afraid of using javascript technologies in their projects. Who knows, maybe it'll help the overall plone community javascript skillset...

1 Like

and that's exactly the argument I used against using CoffeeScript: "tomorrow somebody will came with the next new cool thing to do this and we will have to refactor the whole stuff".

that's why I really hate the whole JS development environment: is so fragmented and so short lived that I don't care to learn anything.

I agree, if they are your packages, use whatever you want; packages on the Collective are community packages.

Babel looks awesome, BTW:

https://www.quora.com/What-do-you-prefer-and-why-TypeScript-CoffeeScript-or-ES6-with-Babel-compiler

We are using Babel for an in-house ES2015 SVG rendering system, and really like it. But I suspect the typical Plone workflow for Coffee/Typescript/ES6/etc is likely to be use external build tools and push the compiled ES5 assets into your add-on.

Here is what we do:

(1) ES6 code in stand-alone repository, built into local asset "build" directory. Gulp wraps webpack and Babel builder for Webpack. Gulp runs CSS pipelines, webpack only runs JS pipelines. Gulp test server is used for local testing across browsers. We do not keep built assets in this repository, at all (via .gitignore).

(2) When asset is ready to build, I have a --release flag used in my gulp, webpack config that makes both regular and minified assets. After this runs, I use a bash+applescript trick to copy files and open the destination directory in a new terminal pane (iTerm2):

(3) We commit the derived assets into the downstream (Plone add-on) package. We pack our git repos sometimes for space, but this has not been an issue for use yet.

(4) Doing the above can (I guess) facilitate pushing a script into any environment (Plone 4 or Plone 5), but the details of including that script vary.

(5) At some point, it would be nice to avoid shipping some libraries twice (e.g. moment.js in default bundle, then I ship moment.js again in my compiled asset).

Sean

@vangheem It is a community package, not my own package.

@hvelarde Ok, I thought that using something with syntax close to Python would be good to the community (Ruby on Rails community moved in this direction), but I don't care to use Babel instead if you prefer.

@seanupton I'm using Yeoman to help with static files management, and did some integration with buildout, for me it works great.