Atom moving to JS?


#4

There ‘sort of’ was (briefly mentioned in an issue on gihub) but I can’t find it now.


#5

That is kind of silly to say. Coffeescript transpiles to JS, so yes, obviously the latter is ‘supported’, however all source code and official examples etc. are in Coffeescript which is a major turn-off for many people (myself included)


#7

I just replied to your comment, you may have not noticed but no hate was expressed.


#8

Sorry. I assumed incorrectly.


#9

New files being added to the atom/atom repo are all being written in javascript:

Electron made a complete break with Coffeescript recently:

Presumably there will be a day when atom/* no longer contains *.coffee files.


#10

That’s quite a presumption. I doubt they would take the trouble to go through and rewrite a couple of years of code. Also, many in the community will still use coffeescript. Using Javascript would be a major turn-off for me.


#11

I doubt they want to carry the technical debt associated with Coffeescript indefinitely. No one is saying you won’t be able to write packages in Coffeescript just that the core of Atom is not using it going forward.


#12

Over a year ago they said they were getting rid of space-pen and jquery yet I run into it in the core code all the time.


#13

The same goes with ES6, as long as chrome doesn’t support it fully we have to use babel, and since the preset used is the es7 one, you can be sure that a lot of code will take advantage of it (i.e. decorators), and will have to be supported, rewritten the same way if features are dropped from the standard or when when babel’s hype will be over. Is that any better?

On a side note, I’m always amazed to see how some people can pretend than one language is a show-stopper while another is not, given than 90% of their features are common (I mean, what’s the fundamental differences between coffee and es6 these days? beyond significant whitespaces). I’m not referring to you @john here (the fact I replied your post could create some confusion), it’s just that there’s a trend of CS bashing lately that I don’t find really useful nor healthy.
For me, all this ruckus is just another example of the magpie developer syndrom in action. Just like with pretty much all the JS world these days.


#14

But the beauty of Babel is being able to swap it out. Swapping out Coffeescript means a rewrite, either of raw Coffeescript or of the transpiled JavaScript.

In theory, using Babel, we can just drop the transpilation without any issues. I’d hope that there are style guide rules restricting use to ES2015 for now, but if package writers want to use ES2016, that’s fine Babel or similar will keep it ticking away. But I’m trusting that if Atom does make a switch to ES2015, that it’ll be well-managed, and hopefully we’ll see the benefits of all the nifty ES2015 features running natively.

I feel we’re at a point where JS versions are coming around much quicker (at least that’s the idea), and by tying everything to a language that looks like it could (maybe it won’t, who knows, maybe we’ll be seeing CS2016) become obsolete.

Ultimately, I’m indifferent, but if there isn’t much difference in functionality it makes more sense to me to move towards the ever-evolving JS, than be stuck with all the oddities that may arise from legacy Coffeescript.


#15

True, as long as there’s no fancy plugins enabled.
And I’m quite wary of the subtle differences between babel and native implementation that could arise. I’m using meta programming a lot, and I already had to make up for how babel emulate ES6 classes, and I can’t guarantee that it’ll work with native ones.

I hope so, but I’m not really confident about that. For instance for…of and generators are practically unusable in performance critical code. Babel generates a lot of guards in the loop (since it has to check whether it should use an iterator or not and wraps everything in a try…catch) and chrome simply don’t optimize such code. Which lead to awfully slow code in comparison with what a CS for…in loop produce. Which mean we still have to write crappy for loop and take care of common optimization ourselves (like storing the length of arrays prior to the loop).

That’s where I tend to differ, I think the oddities are more on the babel side than on the CS one. CS have been always reliable, even on IE6. Babel’s is >= IE9. And the fact that it try to implement official features that are not even implemented in browsers is much more prone to differs from upcoming implementation than CS, since it just don’t care about that: It has its own set of features that are carefully implemented with ES3 compliant JS.

Anyway, I’m using ES6 more and more as well, partly because I feel the syntax is making it less painful to write tests (like having to type function () { every two lines), and partly because it’s obvious that when people are reluctant to read/write CS you’ll have a harder time finding new contributors.


#16

Am I the only one who thinks that Atom core should be written in plain ‘old’ ES5 ?

Sure the syntax is a bit more verbose (you can still omit semicolons if you don’t like them btw)
But ‘use strict’ already solves a lot of JS’ birth defects.

Isn’t it best to use the most well-adopted and most performant standard out there for the core codebase?

Using ES5 also means that there is no extra compilation step so debugging is better and it is 100% future-proof.
Compiling dynamic languages is kind of silly in my opinion.

If people want to write packages in Coffee or Babel - there is nothing stopping them, is there?

PS nobody is actually typing ‘function’ these days, you just type ‘fu’ and press ENTER, so whats all the fuss about?


#17

Many of the advantages of coffeescript can never be replaced by ES6 because of the need for backwards compatibility. As an example, JS can never get rid of the noisy C syntax.

Yet coffeescript can add the features ES6 adds, like generators, which were in coffeescript over a year ago.

So CS has and will have a permanent advantage over JS.


#18

Syntax is a preference thing, so that is a bad example.

The main disadvantage of CS is that it will never be native and will always have to be pre-compiled.
So debugging will always be worse than that of a native code.

CS may have some advantages over JS, but it also has a load of disadvantages.


#19

Ok, then how about the fact that CS is much more of a functional language since everything is an expression. There are other semantic advantages. Also, isn’t everything, including features in ES6, just a preference thing? You could prefer to write in assembly language. This whole discussion is about language preference.

It isn’t a significant problem to me. Even when I have to deal with javascript directly it is no problem since I can easily tell what javascript is created from a CS statement. It is one-to-one.

I only know of two. The debugging issue and coffeescript-haters (I use that term loosely) not contributing to coffee-script projects. Pre-compiling is a non-issue. I don’t even know it is happening. What am I missing?

BTW, did you see the thread about my project attempt that gives ES6 a syntax wrapper with CS syntax? It would not be a trans-compiler, just syntax converter. I would switch to this if it existed even though I would lose some semantic features. It would solve all problems including the non-contributor problem since it would be two-way and allow one person to edit with the wrapper while others see clean ES6.


repo: https://github.com/mark-hahn/jsw

Unfortunately I am stuck on the two-way feature at the moment and it may not be possible. My current solution adds a lot of superfluous git changes. Without the two-way feature it isn’t worth doing.


#20

BTW, one more drive-by snipe. Doesn’t the fact that ES6 copied coffescript say something about the two? Imitation is the most sincere form of flattery.

(And yes, Brendon and others specifically state that they were copying coffeescript).


#21

As someone once said - I know the meaning of each of those words, but the way you put them in a sentence does not make sense. Can you please elaborate? (Perhaps a couple examples would help)

Maybe you have not mastered the debugging tools enough to feel the difference?

You are saying it like everything was copied.
In reality its just a couple of syntactic-sugar thingies that were copied (like fat arrow, etc.)
They were also present in other languages (classes, etc.)

Shall I remind you that CS itself copied features from other languages? (mainly Ruby and Python)

I have not seen your project before, to be honest I am not sure if it would be very useful.


#22

OK, you win. CS sucks. This has just turned into naysaying.


#24

Unfortunately, this has turned into a copy of

So I’m going to close the topic because there isn’t a productive discussion that is going to come from this.


#25