No more Coffee. Decaffeinate the Atom's Core. Atom without Coffeescript


#1

Prosperous 2018!

OBSERVATION
Today I read through some notes presented in
https://atom.io/releases
The core code of Atom is transforming from CoffeeScript to JavaScript.


QUESTIONS
Why would the motivation be to switch to JavaScript?
Historically Atom was pushed to CoffeeScript by Github fellows against overwhelming public opinion and heated debate to keep with JavaScript.
Does this change come because of the partnership with Facebook?
Would the next move be to transition to Microsoft’s TypeScript?

Indeed a bold move… probably a positive one.

Would CoffeeScript fade even more now?



-- related --



ES6 imports not supported in atom? (Solved?)
#2

When Atom was being rewritten to use Node ES6 was still in early development. ES5, with its lack of support for classes and verbose syntax for inline callback functions (among other downsides compared to ES6) meant that CoffeeScript seemed like a really nice choice in order to improve readability. This next part is mostly speculation, but CoffeeScript and Ruby are very similar. And since many GitHub engineers are proficient in Ruby, that’s yet another reason to use CoffeeScript over JavaScript to lessen the learning curve for any GitHub employees that wanted to tinker on Atom.

Now that ES6 is fully supported by Node/Chrome there’s almost no more reasons to use CoffeeScript. And now that Atom is open source the opposite argument can be presented - that most contributors are more likely to be familiar with JavaScript than CoffeeScript. I’ve also found that moving away from CoffeeScript allows us to remove outdated build pipelines (eg https://github.com/atom/atomdoc/pull/17#issuecomment-351221744).

My answer is no, but I am not a GitHub or Facebook employee and my answer should not be taken as an official response.

Happy new year to you as well!


#3

I would like to answer as someone that has done a lot of coffeescript and javascript; including ES6 plus a whole bunch of about 13 other languages. I am biased toward coffeescript. I have reasons to be - because I have effectively used it increase extendibility, reusability and developer (me) productivity. I’ve seen others do the same.

Key things that make me productive in coffeescript:

Existential Operator

I have solved more issues with a single ? than I can count. I use to ask people I was interviewing who said they were 4 out of 5 in javascript to show me how to test for existence. I stopped asking that question because, well, that and knowing how to code prototypical inheritance must be esoteric Javascript features.

For example:

someValue = @state.userEnteredValue ? @props.value ? @context.value

when asked to do the same thing most will answer:

var someValue = this.state.userEnteredValue || this.props.value || this.context.value

That answer is of course wrong because the intent is to take the userEnteredValue which may be 0 and in that case we ignore the userEntered value because it’s false when zero.

The actual solution in Javascript looks more like this:

var someValue = null
if( typeof this.state.userEnteredValue !== undefined && this.state.userEnteredValue !== null ){
   someValue = this.state.value
} else if( typeof this.props.value !== undefined && this.props.value !== null ){
  someValue = this.props.value
} else if(  typeof this.context.value !== undefined && this.context.value !== null ){
  someValue = this.context.value
}

And there are more time saving use cases like, check that an object instance foo exists, has a member bar and that bar is a function and if so call bar():

foo?.bar?(baz) 

way too long to type out in Javascript. Which brings me to my next most productive thing about coffeescript:

A lot less code.

Contrary to what you may be told there is no glory in writing more code to do the same job. Any more than using semi colons at the end of lines when the language hasn’t required them in over a decade (?) is going to make your code any more ‘solid’.

If someone sent you a pull request that said you could make your users 20% more productive, you’d take it wouldn’t you? But when I tell you that you could touch that keyboard 20% less and achieve the same results you say no. “What a strange planet.”

Note that since the coffeescript compiler strips out comments, the actual difference is greater than 20% less. Where does it all go?

Stop being programmed and start programming

If a compiler (eh hem, Java) can tell you when you forget your semicolon at the end of a line, why can’t it just pretend that it’s there and move on? Why can’t we seem to move on?

var, function, and let me see })}) or was it }))}, I don’t know or want to keep track that stuff. You’ve been programmed. gone.

Object Oriented ES6 is kinda not quite there yet

Things like no prototype static initializers and this not being accessible in the constructor seem half baked. Just one example: https://benmccormick.org/2015/07/06/backbone-and-es6-classes-revisited/

But let’s be honest, if you’ve never done coffeescript, Java, Ruby or Python, if you only know javascript and say PHP really well, I’m going to guess the next thing you say to me is, “OOP is dead gramps, there is the new thing called procedural programming”. “Oh you mean like C or Fortran? I loved C once.” We’ve been here before and will again. But yeah, know that people saying we don’t need classes and inheritance are probably arguing that case from the standpoint of being deprived of it for so long.

so, so much more, but you probably don’t care

It’s sad that a lot of statements I read about why we should all be doing Javascript ES6 and not coffeescript seem to come from people who have done very little coffeescript and have no desire to learn it. To which the argument goes that well it requires learning and Javascript you would still have to know. You will, after 6 months, if you have a reasonable IQ, just see code written in both languages. I turn off sourcemaps and encourage my team to also. Seeing what javascript is generated by coffeescript and debugging it “natively” is second nature now and is helpful in catching bugs sometimes that have nothing to do with either language.

So, given the choice of ES6 or coffeescript to write my next package for Atom, I will certainly choose coffeescript.


#4

Hello @Bee .

Your reply is valued - thank you. Your notes introduces me to some good insight. I hope the following opinions are favourable for more discussions on Coffeescript and Coffeescript in Atom.

This reminds me of the video tape format war: Betamax vs VHS. We had to make a second purchase in the early '80s.

You and I should concede though that the best “engineering” solution, do loose the popularity contest at times. The opinion of the crowd has a huge influence.

I am not a programmer in the sense of designing applications for PC-like systems. My niche is engineering industrial machines. There is no claim of knowing which is best even if I prefer seeing Coffeescript. This subject matters to me only for hoping that Atom thrives.

Perhaps Coffeescript as a language will survive not being used in Atom as much as it once was. Decent Coffeescript tutorials seems hard to come by. (I wish I knew more.) If this is true, then Coffeescript stands no chance.

My observations relating to what Atom is coded in:

  1. Coffeescript has functionality that Javascript struggles to give. The backbone of Atom’s core was already in Coffeescript. There is an engineering tax still to be paid for switching languages for Atom. Opinion: It is for me more easy to follow/read than Javascript.

  2. Javascript is more popular. Using Javascript in the core of Atom has the potential to attract more people to join in to develop Atom. Opinion: People are reluctant to learn Coffeescript; even if technically better.

  3. Companies designing bigger Javascript-family type programs tend to use Typescript. Typescript is inherently better for bigger projects or bigger teams. Perhaps a better option to use for Atom.

  4. Opinion: The decission to move to Javascript catches me by surprise. (Was there any blog entry about this?) This makes it “feel” as if the public is not looped in on descissions made. (Not saying it is the public’s place to debate this.)

To capitilize on the efforts for port over to Javascript -
The fact that Javascript is now being used should be pushed as heavily as Teletype was. This has the potential of getting new blood into the project.

If this move does not attract new talent (even if it from Facebook), then it would have been better to keep with the better engineering choice that is Coffeescript.

Regards.
- Dan


#5

@Bee I agree 100% on many of your points about CoffeeScript’s enhancements over JavaScript, especially the existential operator. That is something I sorely miss when converting code to JS or having to check for existence (though thankfully, || usually works if you’re not dealing with numbers). However I don’t enjoy how Coffeescript creates variables for you and puts it at the top of the scope, as that means it’s impossible to use const and such. There’s been more than one Atom bug that would have been prevented by using const path = require('path') in JS.

I think @danPadric’s observations are spot-on, though I’m unfamiliar with Typescript so I can’t comment on that. No, there was no blog post. It was more of a gradual realization of “why are we still writing CoffeeScript when ES6 gives us most of what CoffeeScript has to offer (and some more, like async/await) and most of the community is more familiar with JavaScript?”.


#6

Thank you for you reply and compliment.

Yeah… the scope of variables in Coffeescript can sure raise havoc on someone who uses Javascript more. Plenty of blogs warn of this… bit its hard to “switch off” these habit.

I tried using _ key infront of the variable name for what is used in a local/limited scope.
I use this to indicate ‘temporary tags’ in the SCL coding of code blocks for industrial PLCs.


#7

I like CoffeeScript for pretty much the same reasons that @Bee has provided. It’s oftentimes faster to write code and IMHO reads much nicer – but the later is entirely subjective and probably influenced by my experience with both Python and Ruby. However, I have never used CoffeeScript before I started developing packages for Atom and I have never used it anywhere else.

Despite my personal preference, I think moving away from CoffeeScript is the right thing to do. In part the developers of CoffeeScript are to blame for this. CoffeeScript 2 introduced many new features to put the language en par with ES6. However, the many breaking changes would make it a huge effort to port CoffeeScript 1.x to 2.x. I don’t think it’s worth it. For us package developers it will not matter, since everyone can continue to use what they like best – CoffeeScript, LiveScript, TypeScript, (maybe even BuckleScript?) or plain JavaScript.

Earlier last year, I’ve read this very convincing article by a developer of Slack, outlining the reasons for moving to TypeScript. Basically, they claim to have reduced their syntax errors by 50% just by moving from JavaScript to TypeScript. I used TypeScript myself for smaller projects and I can related to that claim. I think the article makes a strong point to use TypeScript, even more so for huge projects. So, I was a bit surprised, the Atom developers don’t follow this trend.


#8

So will all this mean that eventually, packages written in CoffeeScript will be deprecated? Or will Atom be moved to Javascript but the ability to write packages in CoffeeScript will remain?


#9

@TheOriginalRedHood I imagine that packages written in CoffeeScript will continue to work for the duration of Atom 1.x. I know there’s been discussion of changing how transpilation works and possibly making packages transpile themselves but that still seems far off.


#10

Now THAT is an important point. This is probably a bigger push to go to JS than anything else. Would this be as significant as Python 2 vs Python 3? (rhetorical question)

I hope that is taken seriously… better sooner than later


@Wliu: Any recipe you could suggest if people are thinking of decaffeinating their package projects. Opinion: It would be nice if this is mentioned in the Flight Manual at some point.


To me if idleberg says that, it is good enough for me to request the Atom curators think hard if they should not continue to port over to Typescript.


#11

Run it through decaffeinate and give it a manual cleanup afterwards, mostly just removing unnecessary returns and such.

The breaking changes aren’t that bad though keep in mind that there are over 7000 packages at this point (not necessarily all Coffeescript, but still).


#12

@Bee: Would you be so kind to answer some queries, please.

  • Do you have any projects running on V2 yet?

  • Do you have any thoughts to share on the breaking changes introduced in Coffeescript V2?

  • Are these something that an auxiliary script can ‘repair’ automatically?


#13

I feel like it’s probably best for Atom to be constructed in vanilla JS as much as possible because it’s something the whole community understands at least a bit. When I started on Atom, I was doing mostly CoffeeScript and Python, and through CS I learned to read more complicated JS code well enough that it was easy for me to start writing it and switch to ES6 full-time. If Atom is written in the common “mother tongue” of all the various transpiled languages and frameworks, it’s easier for each individual developer to use their preferred dialect and vocabulary.


#14

I still think my earlier points about the language and productivity are valid, but after careful consideration of all vectors, my neuron network has concluded that it is time to switch to ES6 and beyond.

I’ve spent the last couple of weeks in the sun reading.

About CoffeeScript 2, yes, I did, but as @idleberg above noted and I filed an issue on, there are too many breaking changes. Any port from Coffeescript 1.x to 2.x would be almost as much work as porting to ES6.

I also gave a brief look at Typescript and tried to put aside my past regard for a company that puts proliferation and profit over great design and engineering. Again, I’m sure I would find ways to be more productive than vanilla JS with it, but… What is my cost in supporting it? Will I have tools that will work with it now and in the future? Plus the other notable considerations from conversations above and with others that DO clearly understand CoffeeScript and JavaScript.

My remaining consideration is to Flow or not to Flow. My hypothesis is that that static code analysis against a dynamic runtime language will only catch a small percentage of defects and will add zero percentage improvement over having 100% test coverage. Now if I only had time to experiment. :sun_with_face:


#15

Just for the fun of it, I created a Yeoman generator that templates Atom packages, that compile CoffeeScript (v1 or v2) on install time.

Parts have been modelled after package-generator, but with some extra sugar like CircleCI/Travis CI support, husky-powered git hooks, or a more useful README.md.


#16

+1

Maybe it is just ‘yet another new language fatigue’ but seems to me that the (development) world does benefit when it eventually coalesces around a smaller toolset with more robust support/enhancement/development.


#17

Parts have been modelled after package-generator, but with some extra sugar like CircleCI/Travis CI support, husky-powered git hooks, or a more useful README.md.

Same thing for TypeScript: