Atom Shell is now Electron
blog.atom.io
blog.atom.io
https://github.com/atom/electron/blob/master/docs/developmen...
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
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...).
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.
Slack, Mapbox and more.
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.
It is the, well, shell of the Atom editor.
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".
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).
> 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.
- 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.
having it be that deeply associated with the other brand reduces the visibility of the project?
EDIT: here's a demo app with zero CoffeeScript: https://github.com/thom-nic/electron-demo
Also, it's nice to work in a language that has the right features and not just all the features. I like CoffeeScript as much for what it doesn't have as for what it does have. I recently saw this piece of code:
new Array(26)
.map(function (item, index) {
return String.fromCharCode(65 + index);
})
const caps = new Array(26).map((item, index) => String.fromCharCode(65 + index));
Someone will probably chime in here with a correction, but the point is this -- JS is NOT a friendly language to deal with.
For example: [1,2,3,undefined].forEach(ele => console.log(ele)) > 1 > 2 > 3 > undefined On the other hand: [1,2,3,,].forEach(ele => console.log(ele)) > 1 > 2 > 3
So, take the time you dedicate to hating JavaScript to understand the language instead of bitching here you and that stupid jerk above.
new Array(26).length === 26; //trueJSBin: http://jsbin.com/vasulumeti/1/edit?js,console
StackOverflow: http://stackoverflow.com/a/5501711/211291
Array.apply(null, Array(26)).map((_, index) => String.fromCharCode(65 + index)) [65..90].map (number) -> String.fromCharCode(number)
Because it's the shortest way to do it in that language.
I think something like:
[A-Z].reverse
reverse([A-Z])
for (1 = 65; i <= 90; i++){...}
const caps = new Array(26).map((item, index) => String.fromCharCode(65 + index));
const caps = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'.split('');- https://discuss.atom.io/t/why-coffeescript/131
- https://meta.discourse.org/t/is-it-better-for-discourse-to-u...
More people are familiar with Notepad than vi. Does that make vi a bad choice?
That analogy doesn't work, because editors don't have network effects, whereas programming languages do.
The 82 plugins in my current vim setup really, really beg to differ.
Appropriate tool, appropriate job.
Ignore the haters, they will always exist. Just keep build great stuff.
He is only stating his feelings. He's not trying to put anyone down or argue that his way is better. Unlike a lot of the comments.
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.
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.
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.
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?
...
> 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?
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.
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://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...
Additionally it's also a bad name because it's impossible to google.
Very different to passwords, which should be computer-generated and computer-stored, you should never know your passwords.
I forget which language it was, but someone interviewed the creator and he said if he had to do anything different he would not have named it something so hard to google.
Apple? C? when something gains critical mass it's really irrelevant anyway, since they become easy to google (atom shell is already a front page result for "electron").
or is the argument that they are bad names because they are not "relevant"? again.. Apple... C... if anything i'd say "electron" is super cliche and exactly the type of name i'd expect a library to have.
It's not the only one, but it's certainly important. Especially for more obscure projects, or things that users will have lots of question about, if you can't google it, it's not going to succeed.
> Apple? C?
Really? Those are you examples? Both of those were named before google even existed. They are very large, and hardly obscure. They don't need any help to be found.
> or is the argument that they are bad names because they are not "relevant"?
No, that's not the argument.
> if anything i'd say "electron" is super cliche and exactly the type of name i'd expect a library to have.
Maybe you expect it, but it's a terrible name.
"bad name" is, i'm sure you understand, in every instance, completely subjective. and your stance stands under scrutiny particularly in software, where names like this are ubiquitous.
to defend my examples, which for some reason you considered an exhaustive list, i present rails... bootstrap... backbone... react... apache... steam... chrome... express... should i keep going? even Yale's Neuron simulator is named NEURON.
my point is that your opinion seems to be the minority. which is fine, just gives you no ground to call your opinion "fact".
Hu? You are aware that programming languages are not human right? So how does one "dehumanize" something that isn't human in the first place?
> the purpose of a name is not to maximize discoverability.
Actually, yes, it is. That is the number one goal of the name of a programing language or library. If I can not easily find out more about your product then you might as well not release it.
Are you confusing the names of humans with the names of programming languages? They serve different purposes.
And just to strengthen my point, actor names are required to be unique, if the name is a duplicate they make them change it. Yes, the actual human, is required to change their name. The actor guild understands what good names are.
Of course most people do not need to be searched for, but some do.
For example politicians with good names get more votes than those with bad names. (A good name for a politician is something easy to search, easy remember, easy to spell, and hard to make jokes about.) You might not like this fact about elections, but it is nonetheless true.
> do you feel the same about band names?
Depends. Do bands need to be searched for to get additional information about them?
> to defend my examples
Wait, so you are defending your example, by giving me more examples of bad names? How does that defend anything? You are just making my point for me.
Go search for some of those names, are see how the results are a mixture of different things instead of just the topic at hand.
I guess you have never come across some obscure language, and try to get more info about it, only to have most of your search results be about entirely irrelevant things?
Once you experience that you'll understand, that yes, it's a fact, not an opinion.
you'll have to forigve the length of my response here, it is my only defense for someone so patronizing.
> So how does one "dehumanize" something that isn't human in the first place?
you could deduce i was not referring to the dehumanization of software, i referring to the dehumanization of the art, rhyme and reason behind naming things. your notion that discoverability is "the number one goal of the name of a programing language or library" is also an opinion, and i posit that the authors of all the software i listed would consider it your opinion as well. that, or they are all incompetent.
in my previous post i tried to treat "discoverability" as a valid argument with respect to these names, but i must admit it sounds imaginary. all of the examples i provided, are by your measure are undiscoverable therefor "bad". yet somehow, everyone still finds them just fine, they are all insanely popular, Google returns the proper results on the front page, and the world keeps spinning.
> And just to strengthen my point, actor names are required to be unique, if the name is a duplicate they make them change it. Yes, the actual human, is required to change their name. The actor guild understands what good names are.
the actors guild doesn't give a shit about "good names", they give a shit about protecting actors. that is why they exist. the reason they restrict unique names is so i cannot start acting under the name Jack Nicholson, receiving undeserved credit. does USPTO require unique trademarks because they "understand good names"?
> Depends. Do bands need to be searched for to get additional information about them?
of course they do. just like a painting or song must be searched to find additional information. so band, painting, and song names are "bad" if they are hard to Google? this is what i consider dehumanizing. a name is a form of expression.
if i am naming my song, my band, or my library, i really don't care if you have trouble Googling it. i'm not naming it for you. and if my song, band, or library is of value to people, it will become discoverable despite it's name.
> Go search for some of those names, are see how the results are a mixture of different things instead of just the topic at hand.
if your query does not return the results you want, it is your responsibility as a user to refine your query. for example, if you tried to Google "meteor" with the intent to research the space rock, half the front page results will be about an irrelevant software library. by your logic, this makes "meteor" a bad name for the space rock.
> Wait, so you are defending your example, by giving me more examples of bad names? How does that defend anything? You are just making my point for me.
i am providing more "bad names" to prove my point that either you need to recalibrate your measure for "bad name", or everyone else does.
> I guess you have never come across some obscure language, and try to get more info about it, only to have most of your search results be about entirely irrelevant things?
this is a loaded question. the definition of obscure here is "hard to Google", so of course an obscure language would be hard to Google. that said, even 8 years ago i had no trouble researching the Io language, when it was harder to find on Google than it is today. this is part of my basis for calling your argument imaginary.
there are nearly infinite examples of things succeeding despite their name being initially undiscoverable, and it is impossible to prove a single case where something failed because it's name was hard to Google. why am i defending the only side of the argument that has data to support it?
[1] http://en.wikipedia.org/wiki/Acorn_Computers