Supporting CoffeeScript

[famous]

Supporting CoffeeScript

[andrewdeandrade]

@jdiaz5513 We have no plans to support coffee-script. Support for compile-to-js languages is an exercise we plan on leaving up to the community to solve. With that in mind, feel free to create your own generator for coffee-script.

Furthermore, once we start curating and promoting re-usable modules within the community, we will probably not curate or promote compile-to-JS modules, examples or tutorials, unless they offer significant benefits in terms of what is possible in vanilla JS (e.g. some projects like clojurescript core.async and swanodette/mori are examples of exceptional projects). If something is meant to be shared with the community and can be written in vanilla-JS, it should be. Some homogeneity on bikeshed issues in a community is valuable since makes it much easier for developers to jump into someone else's code and contribute, and increases compatibility among and inbetween projects. The PEP-8 style guide in python, testing and documentation standardization in the perl community (CPAN) and the decision to standardize around callbacks and how callbacks are implemented in NodeJS are stellar examples of a developer community not being it's own worst enemy..

"Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, 
mais quand il n'y a plus rien à retrancher." --Antoine de Saint Exupéry

That all being said, feel free to code your own projects up in coffee-script or whatever compile-to-JS language you want.

[gadicc]

Yeah, I don't think a purely front-end framework should be responsible for serving stuff. What about using Meteor? It has great CoffeScript support (including source maps), with live reload on file change. It's also very modular so if you don't want the full stack you could remove e.g. the templating and database code. So it's install; create project; add famous; remove superfluous modules. 4 lines to type :>

[andrewdeandrade]

@gadicc Totally agree that you shouldn't have to use our website serving tools/code, and currently you don't have to since everything is still require.js based. That being said, we're building out an optional toolchain that you can choose to not use (if something like meteor meets your needs and there is a meteor module that can work with famous modules) or that you can use with meteor via a meteor module that executes our toolchain via API calls.

Meteor is but one back-end out there and we're building out a toolchain that works with npm and bower that will eventually offer API access through SDKs for developers using other backends. For example, if you have a go or python or ruby or scala back end, you may not have a javascript toolchain already set up, so it would be useful to have a javascript toolchain that your server could hook into.

Furthermore, famous is not just a vanilla framework. It may look like one now, given the way its currently packaged, but its actually a series of inter-dependent utilities that can be re-arranged and used in different ways the same way unix utilities work. You're eventually going to see tooling that helps you bring in new modules created by us or by members of the community into your project. Once that happens, the famous toolchain will help you get these modules into your project and hooked up correctly. Since we're taking an npm/bower like approach, it's likely that meteor will eventually need an interop layer similar to the one used to interop with npm.

Anyways, I wouldn't worry too much. We're not going to stop you from using coffeescript in your own code and we're not going to force you to use our toolchain (however they will make your life easier). You're free to take the famous front-end code and organize it the way you want in your project.

[jdiaz5513]

I agree wholeheartedly with the current approach to modularity.

I was considering writing up a style guide type example of how to subclass a View using CoffeeScript's class syntax (which, btw, was pretty easy to do), but am deciding against it because I think it is ultimately detrimental.

Part of the beauty of the modular approach is that you can just drop in someone else's View code and start using it (assuming they didn't drag in dependencies outside of Famous).

Despite being a CoffeeScript afficionado I've been writing all my Famous code in vanilla JS for this reason. Anyone worth their salt in CoffeeScript should know how to write good JS, anyway. :)

[gadicc]

@malandrew, awesome, thanks for the detailed explanation. Indeed, I hadn't realized any of that and it's great to get a clearer picture of where things are headed.

[andrewdeandrade]

@jdiaz5513 Exactly, basically long term we're going to be pushing tools that support common conventions in the famous community. The more similar code is between members of the community on bikesheddy issues (syntax, style, docs, tests, etc), the easier it is for every to parachute into unfamiliar code and change and improve things. Fixing bugs and improving APIs is preferable to monkey-patching 3rd party code because the friction of dropping into it and changing it is too high.

@gadicc Obviously, if you have a product you're building and you've got a team with your own shared conventions that differ from those we're establishing, you should not only be free to follow your conventions, but supported in doing so. It's only when piece of reusable code becomes a shared artifact in the famous community that we're going to push for a common way of doing things. This is the general idea behind shirky's essay "A group is its own worst enemy" that I linked to above. If you've never read it, you should. It's very much worth it.

http://www.shirky.com/writings/group_enemy.html

[AdrianRossouw]

I personally have a rule of thumb that it's not ok to write anything in coffeescript that ever needs to be require()'d by anyone else's code. This is really something that can be handled by the community too.

I actually built something using the seed repo from this article :

http://pem-musing.blogspot.com/2014/04/famous-with-gulpjs-and-browerify-in.html

[andrewdeandrade]

@Vertice @gadicc @jdiaz5513 Furthermore, we have some future tools that are going to necessitate everyone working with vanilla javascript insofar as shared community artifacts are concerned. Stay tuned...