Are there any Atom users who aren't hacking Atom?


#17

its very difficult to write plugs that tap into the windowing system without coffee script.

Atom fully supports writing packages in pure Javascript. Check it out.

It helps to be able to read coffeescript in order to look at and copy existing code. Luckily coffeescript is much easier to read than write. I would be surprised if it took any JS programmer more than 30 mins to be fluent in reading CS.

There are also several easy ways to convert any coffeescript to javascript for you to read. I have a chrome plugin that converts to/from coffeescript and javascript with one click.

P.S. I suggest you give CS another chance. Write some stuff in it. You’ll never go back. My philosophy is that if something is better I use it. I don’t care what others use.


#18

Hm. I started with that, but then I had to write a view class. I took a quick look at the generated JS and I saw that there was this custom magic to define classes and to derive classes. So I thought using CS is the path of least resistance, here.

In the last month or two, has there been documentation written that explains how to extend classes in pure JS?


#19

That magic was chosen because it is one of the most common patterns used in JS.

I don’t know. I would be happy to write one. Give me a few days and you can be my beta user.


#20

Oops, I didn’t mean it like that. The magic made sense to me, but then I read that there were other libraries that implemented slightly different magic… So I thought if I use JS I either have to copy the magic which seemed iffy, or use some other utility function that might implement the wrong thing.

Sounds cool. I’m not sure if I want to go back to JS, now. I mean, I tried CS and it doesn’t hurt. But still there is a voice inside me that says maybe it’s not needed. So I’m really of two minds about this. In any case, the docs would be useful to lots of people, and maybe reading it helps to decide whether it’s good to try plain JS :smile:


#21

I read that there were other libraries that implemented slightly different magic

I’m not sure what you mean. I’ve been working with coffeescript in both node and the browser with many libs for over three years and I don’t remember anything like this. Every object paradigm pretty much has to implement objects as plain javascript objects and methods as functions on the instance objects or the prototype object.

There may be differences in how classes are defined, but using a class is pretty much always new Klass(). So I don’t see how the class paradigm would be a problem for CS or you.

Also, don’t forget CS can do anything JS can do. So if you must use another way of implementing classes then just do it. Nothing magical there.

maybe it’s not needed.

CS is definitely never needed since you can always use the javascript equivalent. You don’t need the C language because you can always write in assembly. :smile:


#22

I am not explaining well today. What I meant is that class foo extends bar in CS expands to one method of doing inheritance, but util.inherits does something different. See this post:

I believe I’ve seen yet other little utility functions claiming to do inheritance, yet differently. But those may be pink elephants.

So I got a lost in a maze of twisted little inheritance patterns, all alike :smile:

But your documentation will explain the One True Way to Inherit in JS so that it works well with the Atom view system. I shall be enlightened.

(Takes tongue out of cheek.)


#23

But your documentation will explain the One True Way to Inherit in JS

Yeah … about that. It was the middle of the night and I was full of bravado. That task would be tantamount to writing a book. So I deserved your cheeky tongue.

I’ve just always used coffeescript inheritance in my own classes and extend in node. I never really thought about it. In every case you extend someone else’s class you just have to do it the way they want. How would this be any different in CS than JS?

Classes in CS are just sugar for a common pattern . Many people don’t use the class keyword at all and use whatever they want. I get the feeling that you think CS forces you to do things in certain ways.


#24

@maninsuitcase just to be clear, The built in debugger is the chrome inspector alt+cmd+i on a mac. It’s the same you’ll find in webkit based browsers like Chrome.

A good way to start jumping into a project is to fetch the project’s source at the command like like:

apm develop <builtin_package>

Then run:

atom -d <path_to_package>

Hit alt+cmd+i. Then you can set breakpoints through code, and run things in a REPL console.


#25

Said truly by someone who hasn’t tried it.

If it’s that easy, please! Post a github link to a sample package that implements some complex views purely in javascript, because having done this myself, all I can is that it is 1) not documented anywhere other than obscure forums threads here and 2) when I tried it, it was most certainly not trivial at all.

A demo of how to do this would be most welcome.

‘technically possible if you copy and paste obscure inner bits of the coffeescript inheritance semantics’ != ‘fully supports writing packages in pure Javascript’


#26

True, but then… that’s just the way Javascript works, which is why using Coffeescript is so much easier and preferred by the core developers.

It feels like unnecessarily complicating your life. Atom even auto-compiles your CS for you, so it’s not like you’d be adding an extra step to your workflow.
If you are a Javascript dev already, the learning curve to start using CS is one or two evenings, while learning to code for Atom exclusively in Javascript, as you point out, could potentially give you headaches for weeks.


#27

Quite so; the decision in atom to support coffee only was theirs to make. The only points I was making are:

  1. The set of developers who use javascript is significantly greater than the set of developers who use coffee script. This has unquestionably limited the number of people developing atom packages.

  2. Atom does not simply support javascript; people keep attempting to assert that this is so, but it is simply not true. What’s true is that it’s technically possible to reverse engineer a package that runs only in javascript if you’re very very careful.

So yes, there are plenty of people out there who don’t hack the editor, because of these choices.


#28

Given the amount of packages that have already been created, I think your point 1) is true but probably negligible.
I’m not sure I get your second point though.

To my knowledge (though I haven’t tried myself), you can replace any coffee file with an equivalent JS file. However, if you’re saying that finding out the right way to create such an equivalent file is non-trivial and undocumented, than that’s my impression as well.
A tutorial for that, from someone who has done it, would indeed be very useful.


#29

Sorry guys, but I fail to see why all this discussion about CS/JS. CS compiles to JS, so obviously, everything that is written in CS is transpiled in JS and can be written directly in JS. CS only change the syntax and available sugars to make reading/writing JS less painful.

So here’s a recap of the CS class sugar (and I guess the ES6 one is pretty close to that too):

If you write in CS the smallest code that use inheritance you’ll probably end up with:

class View

class MyView extends View

Using the Try CoffeeScript tab on the CoffeeScript page to compile that code you’ll end with:

var MyView, View,
  __hasProp = {}.hasOwnProperty,
  __extends = function(child, parent) { for (var key in parent) { if (__hasProp.call(parent, key)) child[key] = parent[key]; } function ctor() { this.constructor = child; } ctor.prototype = parent.prototype; child.prototype = new ctor(); child.__super__ = parent.prototype; return child; };

View = (function() {
  function View() {}

  return View;

})();

MyView = (function(_super) {
  __extends(MyView, _super);

  function MyView() {
    return MyView.__super__.constructor.apply(this, arguments);
  }

  return MyView;

})(View);

Now let’s look at the key points here:

Classes are JUST a function with a prototype. Like you’re told in pretty much every tutorial on OOP in JS.

The __extends method that is used under the hood to produce inheritance do three things:

  1. It copies all the owned properties of the parent function into the child function. This is inheriting class members.

  2. It creates a new object whose prototype is the parent prototype, and use that object as the prototype of our new class. This is inheriting instances members. And this is roughly equivalent as doing:

MyView.prototype = Object.create(View.prototype)
  1. It creates a __super__ property on the child constructor that point to the parent prototype. This is what allow CS to resolve super methods calls. If you need to do that in JS you’ll have to write the same code to access the parent class members:
MyView.__super__.method // You access an instance method of the parent
MyView.__super__.constructor // You access the parent constructor
MyView.__super__.constructor.method // You access a class method of the parent

And to call them in your functions you’ll have to either use the call or apply function’s methods to make sure you use the class or the instance as the this when calling the parent class methods. Which give us the following line to call the super constructor:

MyView.__super__.constructor.apply(this, arguments);

The only remaining thing to know is that if you doesn’t define a constructor explicitly in CS, one is created for you that always call the super constructor. In JS, as you will have declared your constructor function before anything else, you have to make sure you call the super constructor yourself. This is especially true with views as the view content is created in the View constructor.


#30

@abe yes, clearly extremely trivial to do…

By all means stick some code up on github thats practically demonstrates this actually working as an atom package, and I’ll happily eat my words.

Something simple like a little toolbar window the bottom of the editor with a data-bound form in it…


#31

Maybe if someone provided the CS __extends function, then it would become easier to write the JS manually.

My understanding here is: if I want to extend an existing View class, then I have to use the CS way to do it. Is that true?


#32

The View class is just a convenience made available for the package devs, it never have been a requirement.
It extends jQuery so that you don’t have to bother with it yourself, but you can completely work around that: this just a webpage with a dom.
Now if you want to extend it, then, yes, it’s better the CS way, because it was written to work that way.


#33

Yes, trivial, took me less that 10mn to wrote that: https://github.com/abe33/atom-js-package-sample


#34

I think the lesson here is that it does require a certain understanding of how the API works. That together with a solid basis in Javascript, should enable devs to make something of it.

And I think this is a good example which would make a good little tutorial for others who’d prefer sticking to pure JS.


#35

I don’t think we should encourage the use of plain JavaScript. Those that want to go that route will always encounter pain, but since there is no benefit to using POJS (Plain Old JavaScript™), they will have to investigate a fair bit on their own.

We should not confuse developers who are new to Atom any more than necessary. By encouraging the use of CoffeeScript, they’ll have a much easier time given the official language of choice is CoffeeScript, for both code and the API documentation.


#36

Few thoughts in no particular order:

  1. Use npm dependencies which you can write in pure js.
  2. Use coffee -c to get compiled js, modify from there.
  3. Try http://js2coffee.org/ (I haven’t used this or similar yet), maybe better yet does an atom package exist for this?
  4. My package (Jumpy) uses VERY little space pen view stuff, maybe it should (not sure), but I don’t. If you take this out of the equation, some of the OO difficulties might be simplified.
  5. Where I work every long time JavaScript developer whether a ruby/python fan or not who tries to switch or is pushed into coffee hates it for 2 weeks and then wishes to never go back to javascript. Very reproducible results.
  6. It’s a myth that coffee is harder to learn for people not learned in javascript.
  7. Currently coffee developers are probably of a higher caliber than javascript only devs (for the time being) Of course this is highly controversial and obviously excludes a bunch of low level JS hackers (plenty of reasons), so we probably shouldn’t argue or ever mention that again :stuck_out_tongue:
  8. I don’t think Coffee will be subject to the same arguments about ‘bloat’ that C++ had with regards to C. Time will tell. But coffee is a lot easier to read / write than JS.