A question I get asked by a lot of people is “Why not just use Coffeescript?”. That question misses a big chunk of what makes Opal useful, I think. Sure, Ruby has a cleaner syntax, but the semantics and features are what make it unique. Ruby has stuff like method_missing and (imho) a better concept of OOP.
What’s the “big win” for you when using Opal aside from the Syntax? Anyone have any good examples?
I really don’t see the point in Coffeescript - it’s so similar to JS that you might as well use JS imo.
Opal, on the other hand, is radically different - not only do you get a much nicer syntax but you can think entirely differently about things and forget that you actually have to do things the JS way.
I think the reason not enough people use it, is lack of documentation.
I’ll see what I can do 
I actually think a really good idea would be the core devs take a break from actually working on Opal for a week, and to work on documentation instead - they can then pass this on to the rest of us to tart up or put into some kind of organised format. It has to start from the ground up though.
Wonder what @adambeynon, @elia, @vais think about this?
I’ve been looking at the (JS framework, transpilier) landscape recently, and almost every new project has docs or had them since first public release - and I think that’s what’s really helped with adoption of them.
I think documentation is an easier one for non-core devs to hop on and take care of. The problem is that when people look for ways to contribute, they think the only way to help out is by adding new features.
And for the record, my previous comment was a sarcastic reference to the screencasting I’ve been doing every week ;-). That’s one of the main reasons I started doing it- to increase the adoption rate of Volt / Opal.
In time, the docs (and ecosystem of help available on Google) will slowly improve.
Your screencasts are great 
Docs are so important though, and I really do think it’s the biggest reason why more people are not using Opal (I mean, why wouldn’t they - it’s Ruby!? haha).
I actually think a really good idea would be the core devs take a break from actually working on Opal for a week, and to work on documentation instead
@AstonJ amen brother. That said, the things I’ve been working on for Opal are already pretty well documented here 
As for the rest of the stuff, your expertise is as good as mine - I have to poke around the source code to figure out what’s what and ask stupid questions.
Wonder what @adambeynon, @elia, @vais think about this?
What I think about this is that Opal needs help with documentation. If good documentation has not happened so far, there are reasons for it, and these reasons, whatever they may be, are still here, so this situation is not going to change, and no amount of complaining is going to change it. @dancinglightning posted an excellent issue to the opalrb.org issue tracker just the other day titled Getting started considered harmful outlining everything that’s wrong with the site (and with Opal docs by extension). And he’s right.
What can be done is for someone (wink wink) to start this “good documentation” project, let it be wrong, and let @adambeynon, @elia, and @meh correct it. If the skeleton is there, if the bones are good, people will contribute to fleshing it out and correct mistakes. I think GitBook works well - it can be a separate repo, like Volt’s. The first step is to just create a good outline, i.e. what chapters do we need, chapter titles, the flow, etc. Then start fleshing it out and reach out to the Opal core for feedback/corrections.
This is just my personal 2 cents, it is not intended to represent the opinions of Opal project owners who can chime in here as they see fit.
TL;DR
…they can then pass this on to the rest of us to tart up or put into some kind of organised format…
I think you got that exactly backwards.
@vais 100% agree
Gitbook or rails guides or whatever are all good to me, if there’s consensus and volunteers I’ll add the repo to the Opal org right away.
I’ll also give all the reviewing support I can as lately I’m doing most of my contributions stealing microbursts of time here and there and it’s unlikely that I get the time to write an essay or a tutorial of any kind.
The other good reason to let non core to do the initial work is that we lack beginners mind and that can cause important omissions or unexplained assumptions.
Thanks for the input @vais & @elia 
I feel there needs to be a starting point - even if it doesn’t make too much sense to begin with, then people can read through it and push changes.
This has worked great for Volt, where many of us have been reading through the docs and sending PRs whenever we feel an improvement can be made - so we are learning and improving the docs at the same time. I also think having docs is a big reason why so many people have taken to Volt.
I would not worry about this - once an outline is there (and easier for people new to Opal to grasp) they can then go on to tweak the docs to make them more beginner friendly 
I really do think that the four of you who know Opal best could make a massive difference by just taking out one week out of development to work on docs, passing these down to the community to brush up.
@vais nailed it, I’d really like to have the time and resources to work on documentation for a week, but currently I just can’t, most of the time I review and merge @vais (awesome) PRs from my mobile. It’s just the way it is for now 
. But as said anyone willing to draft out something will have all my support and help.
Just to be clear I’ll try anyway and do my best to draft stuff in the docs repo, but I kinda know my current limits and don’t wanna give false hopes. 
