Convert mimosa core to JavaScript

[dbashford]

Mimosa's build tool is Mimosa, and as such it can handle mixed language source. Can do this task over time. And, should what CoffeeScript provides remain compelling in some cases, CoffeeScript could be left in place.

[Anachron]

I don't quite understand why? Is this to stick to the other developers choice or does it actually have benefits? As for me, I don't see a problem why coffeescript shouldn't be used. If it's for the sake of less script language learning, you can convert js to cs here: http://js2coffee.org/

[xixixao]

Just chime in, why?

[dbashford]

I've covered this with @Anachron before so I didn't bother elaborating.

JavaScript ensures wider adoption. Some folks see coffee and go the other way. Right or wrong, that is how it is.

[xixixao]

:( I hoped it had a technical reason. One reason I really liked Mimosa was that it was implemented in coffee. Could be either way? Plus do "users" of Mimosa care in what language it's written? :( again.

[dbashford]

I get ya. FWIW it will take me a long time to do this, and I may still keep certain pieces in Coffee for ease of use of things like classes.

And I doubt I'll ever convert some of the modules responsible for doing most of the work. mimosa-require/bower/server will likely never be converted.

[xixixao]

It's also about where you want to put your effort. I get the "putting off" argument, but sane people should care more about functionality - for example curating a nice (rich but well categorized, see brunch.io for "how not to do it" ) collection of skeletons I feel could bring large benefits (adoption).

[dbashford]

Totally agree. This is not a priority for me. I would like it to be done, but I'm never going to sit down and just knock it out. I expect every now and then when I've got a spare hour and nothing else that can get done in that hour I might convert a file over.

Re skeletons, I did some thinking ahead when putting skeletons in place. I've put in place the ability to do some of what you are saying. The skeleton registry forces some categorization. Not using it now, I was waiting for a good number of skeletons to show up before I took on the task of putting an app on top of it. But it's definitely a mid-term goal to put something slick there.

[xixixao]

@dbashford Do you mean the keywords field?

[dbashford]

keywords, server, lang, clientmvc, cssframework, tests, testRunner, requirejs, commonjs.

All these are things you could use for a nice client to place on top of the registry. And with the pattern established, it would be easy to add new data points.

[xixixao]

Yeah, sounds good. I was thinking of adding microtemplating, since it's one of the options you have during install, so you'd probably want to filter on those as well. I can totally see the app.

What I meant though was actually making sure that skeletons don't duplicate too much and that they cover wide range of setups. First you got covered by PRs, the second I guess is left to the community (it can hardly be done by one person alone).

[dbashford]

Adding microtemplating totally makes sense.

I'm ok with some overlapping. Variety is good as long as you can weed your way through it all to find what you need, and variety can be achieved by simply switching out a clientmvc with everything else being the same.

The biggest problem I have is with skeletons being kept up to date. It doesn't take long for me to whip through them to send PRs to keep them updated, but I just need responsive maintainers to handle my PRs.

When 2.0 ship there'll be some changes to make to configs to get the skeletons functional and I'm hopeful everyone is quick to merge PRs.

[Anachron]

I'm still split in half. At one hand, I really like the idea so anyone can make a patch in mimosa and doesn't have to learn CoffeeScript. On the other hand, the code gets bloated with a lot of symbols that makes it harder to read.

In the end, time will tell. You could even translate js back to coffee with js2coffee.

Good job so far though!

[dbashford]

Doing the compilers right now because I'll be breaking them out into individual modules once I am done. Figured it easier to do them in place first.

Sent from my iPhone

---

On 2013-12-26 21:47:31 +0000 Anachron notifications@github.com wrote:

I'm still split in half. At one hand, I really like the idea so anyone can make a patch in mimosa and doesn't have to learn CoffeeScript. On the other hand, the code gets bloated with a lot of symbols that makes it harder to read.

In the end, time will tell. You could even translate js back to coffee with http://js2coffee.org/.

Good job so far though!

---

Reply to this email directly or view it on GitHub: https://github.com/dbashford/mimosa/issues/316#issuecomment-31237193

[Anachron]

It's a smart decision. How will you handle future PRs to Mimosa? Will you allow coffeescript-compiled code as patch or should users just stick to plain old js? It's kinda weird, for Mimosa I learned CoffeeScript and now that I use it daily, it will be removed from core. (Not saying it's bad or complaining)

Another question I have: Will you make compilers handle their own dependencies? So SASS will only be downloaded when the SASS-compiler was active at least once.

[xixixao]

You seem to follow a rather inconsistent spacing style inside parentheses. (then again, big -1 from me for using JS)

[dbashford]

We write CoffeeScript on all our projects. I love CoffeeScript. However for a ton of reasons I'll be coding JavaScript going forward.

1) More people know it, more people can contribute. 2) More people trust it, more people will use the tool. I cannot count on both hands the number of times engineers I respect have scoffed at a perfectly lovely project because it was written in CoffeeScript. I do not, obviously, condone that opinion, but I also do not want to immediately lose people's interest in what I think is a great tool because of a moment of short-sightedness. 3) It's easier to debug something that isn't compiled into code that is difficult to read.

Very, very simply put, it is a barrier to adoption. If you use Mimosa I am exceptionally grateful, but you should want more people to use it. This is a step in that direction. That said, there are pieces of Mimosa that won't get transformed anytime soon. The bulk of core will remain CoffeeScript for as long as I have better things to work on.

I'll be breaking all the compilers out into their own modules. I want those modules to be JavaScript. So I'm modding the code in place.

The spaces in parens thing is a recent style switch for me. I was reading a lot of code recently and came across bit pieces of it that looked like that and I really felt it helped readability. My editor doesn't force that upon me, so occasionally I break from the style and go back to what I've done in the past. I've been trying to catch myself and reread through the code a lot to fix it. I'll keep doing that.

Compilers will handle their own dependencies. The entire compilers config block will go away as each compiler will be responsible for the extensions it cares about and the version of the library to use via compiler specific config.

[dbashford]

Since you asked...

Might still have a bit more to do, we'll see as the other compilers get yanked out, but this is the first one I've pulled out. It should give you an idea of how things will be structured. If you so desire, you can keep track of the changes (mostly deletions) from mimosa core in the remove-compilers branch.

The first of each type of compiler will take some time, but the rest should go fairly quick.

I do expect to take some time with the handlebars stuff. I'll be breaking Handlebars into two modules, one for Handlebars and one for Ember-Handlebars. This way there's no need to configure you are using ember, and no need to keep track of that in the code. You just pick the right compiler.

[Anachron]

I can understand why handlebars and emberhandlebars are split. I'm little bit curious too if there should be some type of bundle helper like mimosa-scriptbundle which will be controlled by the other compilers. As for now its still in the core, right?

[dbashford]

bundle helper? not sure what you mean.

[Anachron]

Helpers that treat a type of file. Like Scripts (CoffeeScript, TypeScript, Javascript etc.), Styles (LESS, SASS, SCSS, CSS etc.), Templates (...) and more.

It's like an abstraction layer ontop of all the compilers. If you don't think the advantages are big enough, feel free to tell me so.