
Atom Shell is now Electron - hswolff
http://blog.atom.io/2015/04/23/electron.html
======
teleclimber
I'm glad to see Electron / Atom-Shell moving forwards, but I wish they'd
publish a roadmap. There are things (like copy/paste) that are lacking and I'd
like to know what the plans are. As it stands it's mostly a wait-and-see kind
of deal, which is a bit disconcerting on big projects.

------
adrusi
What does Electron do differently from NW? I get that one is Chromium and the
other is just webkit, but what concrete, practical differences are there?

~~~
dubcanada
Both are Chromium.

Node Webkit has a forked version of Chromium Source with modifications
(removed the event handler and replace with NodeJS one and a bunch of others).
Seen at
[https://github.com/nwjs/chromium.src](https://github.com/nwjs/chromium.src)

Electron uses the Content framework and has no modifications to Chromium.
Directly calling the required parts from the source (example
[https://github.com/atom/electron/tree/master/chromium_src/ch...](https://github.com/atom/electron/tree/master/chromium_src/chrome/browser/extensions)).

That is the major difference, in regards to architecture. Basically in Atom
you need to create the Window, and in NodeWebkit you always have a Window and
you need to do stuff to that Window.

The other ones include things like backers, NodeWebkit is backed mostly by
Intel, as one of their developers is who is building it. Atom is backed by
Github bunch of others.

------
AdrianRossouw
interesting to see how many things have already switched to building on
electron.

Slack, Mapbox and more.

------
zyxley
This would interest me more if there was a good automatic build process for it
(in the style of node-grunt-webkit-builder).

As it is you still have to do a bunch of the packaging manually (or design
your own shell script for it), and for whatever inane reason, `npm install
electron-prebuilt` only downloads the binary for your current platform, so you
can't even make a replicable build process by using it as a base and using
scripts that copy the different binaries.

------
frik
Is it suitable for WYSIWYG or a plain text & source code editor? Does it
originate initially from Mozilla's Ace text editor?
[https://github.com/ajaxorg/ace](https://github.com/ajaxorg/ace) The name
changes are a bit confusing (Mozilla Bespin -> Skywriter -> Ace ->(?) Atom ->
Electron).

~~~
quanticle
So, it looks like there's a number of things you're confused about. First,
Atom doesn't have anything to do with Mozilla's Ace or Bespin. Ace and Bespin
(now Cloud 9) are tools that live on a server, which you access through a
browser.

Atom is a completely separate project (started by Github, not Mozilla) to
build a native text editor using web technologies. The text editor is a native
application, but it exposes a Javascript API for plugins. After a while,
Github realized that the infrastructure needed to make Atom work (e.g.
installers, updates, notifications, etc.) could also be used by other
projects, so that code was split off into "Atom Shell". It's this project
that's getting renamed to "Electron".

------
yellowapple
Electron's / Atom Shell's homepage isn't doing a good job of explaining what
it is (as someone who's unfamiliar with it). Is it a site-specific-browser
implementation? It's certainly not a "shell" in the normal sense of the term.

~~~
tetrep
>Electron is the cross-platform application shell we originally built for the
Atom editor to handle the Chromium/Node.js event loop integration and native
APIs.

Sounds pretty straightforward to me. They created APIs for Node.js to allow
people to make cross-platform applications, such as Atom (a text editor).

------
hobarrera
Is it me, or does it sound a bit bloated:

> It now includes automatic app updates, Windows installers, crash reporting,
> notifications, and other useful native app features

* automatic app updates : We have distribution repositories for this. * windows installers: Doesn't window have it's own like app store now (market something?) * notifications: which we already had on all major OSs for years.

~~~
RobAley
Obviously you don't have to use any of those features, they won't slow your
app down just by being available (maybe a tiny overhead in distributed code
size, but meh).

\- auto updates : primarily useful for commercial software that isn't
"eligible" for, or chooses not to pay to use, commercial app stores. Or other
apps that for whatever reason don't meet the criteria for public repositories
and don't want the hassle (for the publisher or consumer) of using a private
repo.

\- Windows installers : same reasoning as above.

\- Notifications : I believe its a standardised cross-platform api onto the
existing system-specific notification apis, not a new notification system.

------
netcraft
Im curious about the name change. What do they stand to gain from losing all
of the history of atom shell search results?

~~~
Igglyboo
Atom Shell is no longer tied to Atom the text editor by name. It makes sense
to change the name as Electron becomes more popular in projects outside of
Atom.

------
yzh
I'm expecting neutron and proton too, that will make a whole atom.

~~~
samatman
That's a deuterium, it's a whole particle more than you need.

------
ilaksh
Would it be possible to combine the project with Cordova? I don't use PCs or
laptops anymore because they are outdated.

------
stuaxo
Awesome, may they continue naming things after Acorn computers of the 80s.

------
anon3_
The thing that turned me away from Atom and its' development is CoffeeScript.
As someone who loves idiomatic JS, I still can't get why you'd pick a language
that makes tooling and debugging a nightmare. It's also a kick in the gut to
efforts to fix the shortcomings of ECMAScript like ES6 [1].

[1]
[https://github.com/lukehoban/es6features](https://github.com/lukehoban/es6features)

~~~
picks_at_nits
> It's also a kick in the gut to efforts to fix the shortcomings of ECMAScript
> like ES6 [1].

irony alert: Brendan Eich has said publicly that CoffeeScript was the impetus
for several of the features that made it into ES-6, like fat arrows.

Without CoffeeScript, lots of people wouldn’t have known that they wanted some
of the things that are in ES-6.

As it is, you don’t need CoffeeScript to develop for Atom. Which is part of
the beauty of CoffeeScript. It’s interoperable with what you’re doing today.

~~~
anon3_

      irony alert: Brendan Eich has said publicly that CoffeeScript was the impetus for several of the features that made it into ES-6, like fat arrows.
    

ES6 is a real specification supported by JavaScript engines.

    
    
      As it is, you don’t need CoffeeScript to develop for Atom. Which is part of the beauty of CoffeeScript. It’s interoperable with what you’re doing today.
    

The core of the Open Source project is in CoffeeScript.

Let's say the community had their way, and Atom was rewritten in JS well.

There's still a JS/V8/Chrome for a dependency. On an application where we're
rendering huge walls of text - we forgo native redraw. Crucial to response
time.

It's fun and time-saving _for core developers_ to forgo the grueling work of
portable, native, fast code.

But who pays the cost for the shortcuts?

~~~
BruceM
> The thing that turned me away from Atom and its' development is
> CoffeeScript.

...

> There's still a JS/V8/Chrome for a dependency. On an application where we're
> rendering huge walls of text - we forgo native redraw. Crucial to response
> time. > What makes Atom a viable choice when there already is free, open
> source, native, cross-platform editors with great plugin ecosystems?

I guess maybe CoffeeScript isn't what turned you away?

~~~
anon3_
As a node developer, seeing _any_ official, open source package in
CoffeeScript is a red flag.

The sibling I made a link to a thread about CS in Atom. The creator of
express.js has his take:

 _" Hell I had to rewrite a coffeescript driver this week because I can't have
our company relying on things written by people who are unfamiliar with
javascript, throwing strings, super awkward apis, lots of indirection, and
stepping through the compiled source is a nightmare. It's not like I didn't
want to contribute, I even tried for a while, but it's just not worth the
hell, it was quicker to just rewrite the thing. Not to say all coffeescript
libraries are written poorly, but regardless you're really not gaining much,
just losing a lot."_ [1]

If you write an open source application in CoffeeScript, you're not doing _the
community_ a favor, you're doing _yourself_ a favor. They pay the penalty.

[1] [https://discuss.atom.io/t/why-
coffeescript/131/8](https://discuss.atom.io/t/why-coffeescript/131/8)

~~~
mmgutz
FWIW, that same creator created Jade and Stylus which are pythonic like
CoffeeScript. What's wrong with HTML and CSS? I could never take his stance
against CoffeeScript seriously.

~~~
anon3_
I can't speak for him. I've had fellow programmers love CoffeeScript for their
own personal / client projects - but they conceded that for the real deal - a
public open source project should stay in JS. Otherwise, it'd scare off swaths
of top tier JS coders from contributing. Atom serves as an example of this
practice [1].

The smell CoffeeScript in core gives off to them - _while I don 't subscribe
to this_ \- is that "it's an amateur job, don't bother". You don't write open,
core code in an abstracted language. That's so suspect. Personal / internal
projects are OK, a few I save CS specifically for those situations.

If you look at the source of Express.js, you can see the javascript has it's
own aesthetics to it. You can think of express/connect as serving exemplary of
node.js code, for now.

On a topic of the CoffeeScript creator, Jeremy Ashkenas also created Backbone
and Underscore. These are pretty much examples of top tier JS in the browser.
The projects are known for their annotated source:

\-
[http://underscorejs.org/docs/underscore.html](http://underscorejs.org/docs/underscore.html)

\-
[http://documentcloud.github.com/backbone/docs/backbone.html](http://documentcloud.github.com/backbone/docs/backbone.html)

You can't output this kind of code with CoffeeScript. You have to let in sink
in and understand the patterns (the way .extend works in underscore and how
Backbone builds upon the idea to add it to objects.)

[1] [https://discuss.atom.io/t/goodbye-atom-some-
feedback/12301/3...](https://discuss.atom.io/t/goodbye-atom-some-
feedback/12301/38)

------
jjangsangy
You guys should probably release nucleus before hooli does!

------
ars
That's a seriously confusing name. I thought this was a physics story of some
kind.

Additionally it's also a bad name because it's impossible to google.

~~~
usaphp
It seems nowadays there is no "good" name to google. Every single word in a
dictionary is already being used by something else.

~~~
saurik
Which argues that good names are generally not a single dictionary word. This
is like saying "nowadays there are no good passwords people can't guess:
people can just try the entire dictionary in a few seconds". If you list major
brands, the vast majority of them, even of really really old brands, are
either made up words or phrases.

~~~
scrollaway
The difference is that branding is important. Ease of learning and remembering
a name.

Very different to passwords, which should be computer-generated and computer-
stored, you should never know your passwords.

------
cygnus_a
Wait, this article isn't about physics? boooooring

