Building Nuclide, a unified developer experience(code.facebook.com)
code.facebook.com
Building Nuclide, a unified developer experience
https://code.facebook.com/posts/397706937084869/
15 comments
Why are so many companies hacking on atom recently? First it was MS, and now FB? Anything special about Atom that you don't get in something like Vim or Emacs? They're both open source, and very hackable.
>Anything special about Atom that you don't get in something like Vim or Emacs?
A majority of programmers actually wanting to use it.
While we might use Emacs and Vim in our echo chamber, the huge masses of programmers prefer an IDE or something like TextMate, SublimeText, Notepad++ etc.
A majority of programmers actually wanting to use it.
While we might use Emacs and Vim in our echo chamber, the huge masses of programmers prefer an IDE or something like TextMate, SublimeText, Notepad++ etc.
The speaker was explicit about FB's preference for IDEs and IDE features, and their belief that these features make them more productive. So in that respect their internal majority has already spoken.
Not quite an equal comparison: Visual Studio Code uses only the very core of Atom which allows you to package a browser-based app in a native shell (sort of like Cordova/PhoneGap). Nuclide actually uses the entire Atom editor.
Yes, a native-feeling GUI. Emacs GUI for OSX is ugly and unpolished. Atom's real competition is Sublime, but unlike Sublime it's open source.
I agree; with vim as well, gVim isn't much help to those who still want to use a mouse / don't know the keybindings. Atom is really the most versatile open-source GUI text editor right now IMO.
Well, I think the OP's point is that it would be easier to bring Emacs/VIM up to acceptable GUI editor standards rather than build the whole thing from scratch, as a webapp no less.
But they didn't, my guess is because NIH.
But they didn't, my guess is because NIH.
> Well, I think the OP's point is that it would be easier to bring Emacs/VIM up to acceptable GUI editor standards
I've been waiting for this for literally a decade with emacs. It hasn't happened and I don't have the expertise to do it, so nowadays I exclusively use IntelliJ for the languages I can. I'm probably going to start using CLion with it as well.
There are lots of aspects of Emacs that I miss but I hope that IntelliJ can take them over with future iterations of the vestigial "IDE scripting console". They just need to put a lispy language in there like Clojure and bindings into the editor like Emacs Lisp has.
I've been waiting for this for literally a decade with emacs. It hasn't happened and I don't have the expertise to do it, so nowadays I exclusively use IntelliJ for the languages I can. I'm probably going to start using CLion with it as well.
There are lots of aspects of Emacs that I miss but I hope that IntelliJ can take them over with future iterations of the vestigial "IDE scripting console". They just need to put a lispy language in there like Clojure and bindings into the editor like Emacs Lisp has.
>is that it would be easier to bring Emacs/VIM up to acceptable GUI editor standards
Perhaps but nobody has done it yet.
Perhaps but nobody has done it yet.
And it's not for lack of trying. The last major attempt was Sun Studio on the 90's/early 00's.
Emacs and Vim are like Lisp at this point: unicorns. Perfect, mythical creatures everybody loves to talk about. Meanwhile oxen like Eclipse, Visual Studio, Sublime, etc. keep chugging 90% of the world's code :)
Emacs and Vim are like Lisp at this point: unicorns. Perfect, mythical creatures everybody loves to talk about. Meanwhile oxen like Eclipse, Visual Studio, Sublime, etc. keep chugging 90% of the world's code :)
Keep in mind, Atom was NIH at Facebook too.
And while bringing Emacs/Vim up to acceptable GUI editor standards might be possible (MacVim does an alright job of this), I'm guessing that a lot of the head Emacs/Vim people would be against it, and wouldn't want to merge it back into mainline. That would leave FB having to maintain their fork of it, and splitting mindshare, etc. Atom doesn't need that much work, and it's easier to maintain a plugin than an entire fork.
If it was NIH, then why did they use the existing Atom editor?
I really hope Sublime goes open source someday
I really hope people start paying more for software someday.
Open source != no cost of distribution: https://www.gnu.org/philosophy/selling.en.html
I work with someone who has gotten me thinking a lot more about what software I do and don't pay for. He pays for any software he uses "daily". The payments are either donations to open source projects, service fees, or software purchases.
I work with someone who has gotten me thinking a lot more about what software I do and don't pay for. He pays for any software he uses "daily". The payments are either donations to open source projects, service fees, or software purchases.
In reality there would be a CentOS and everyone would use that instead.
Although this would not be much of a change for Sublime in particular, which is commercial with purchase optional (just occasional nagging.)
Although this would not be much of a change for Sublime in particular, which is commercial with purchase optional (just occasional nagging.)
I paid for Sublime - it's my favourite editor by far. There are ways for companies to support themselves while having their offering be open source though. And I think Sublime might need to eventually to compete
OpenSource often means easy to use without paying. It gives you choice to use but not pay. I am not against open source but most of the time people religiously screaming that this and that must be open source are the ones that never pay for software.
Oh and also replying to the guy above. Tell that to dozens of OSS tools that had to be supported by real companies because people were not that willing to donate. Look at grsecurity for example, tmux, and the other ones i do not remember that Stripe donated 100k to.
Oh and also replying to the guy above. Tell that to dozens of OSS tools that had to be supported by real companies because people were not that willing to donate. Look at grsecurity for example, tmux, and the other ones i do not remember that Stripe donated 100k to.
There is a way, selling support. Do you really see people paying for commercial support of Sublime?
>There is a way, selling support
Which gives you the incentive to make the software less user friendly so more people pay for support :)
Which gives you the incentive to make the software less user friendly so more people pay for support :)
[deleted]
Open source makes a lot of sense for things developers use in common (i.e. language runtimes, compilers, libraries, etc.) because they can all "give back." This is entirely consistent with developers selling application-specific software to other people.
There's no contradiction between the two.
Atom is a graphical editor, unlike either Vim or Emacs. It's much easier for web developers specifically to work on, since it's built with web technologies, rather than vimscript. If I want to change the background color of the file browser pane, I can pop open an inspector, identify the element, and change my custom editor CSS, all within about 2 minutes. Its plugin distribution system also integrates directly into the editor - meaning I can browse for and install plugins from within the Atom itself.
It's much easier to provide a cross-platform rich UI experience with Electron/Atom. It's probably also easier to leverage existing developer skill sets (HTML, JS, CSS, etc.)
its basically an open source sublime and a lot of people like sublimes UI and plugins.
[deleted]
javascript is a much more debuggable language than vimscript and there is far better tool support for it.
I remember Eclipse being forked a lot by various enterprise companies. I guess that's because it had very good extensible architecture. Many developers admitted it. May be Atom is in similar position? Today's fashion shifted from Java to JavaScript and tools are following.
Vim and especially Emacs are also very good at providing extension points.
It's okay hopefully all this gets merged into atom when these projects don't get the userbase they are looking for.
They said they'd like to make this stuff work as Atom plugins eventually
I think they say in the video that they were developing them as Atom plugins from the outset - i.e. Nuclide isn't a piece of software on its own, Nuclide IS Atom.
Yep, you're right - you install Nuclide by using Atom's package manager
http://nuclide.io/docs/setup/
http://nuclide.io/docs/setup/
Heh, they had "pico" in their list of editors. If one is really hellbent on using that for Hack/Obj-C in 2015, I'm not sure whether any argument is convincing enough ;)
Generally I wasn't really that impressed by the demo. Sure, the integration is nice, but I don't see how that's different from most other IDEs. But what struck me as a bit odd was the presenter stating a preference for vim, and then starting to edit Objective-C like all you've got is your cursor keys plus tab.
So, yes, another IDE, yay. And if you work at FB, sure, mindshare alone is probably worth it. But why would one give up normal mode/macros/elisp/abbrevs etc. for that?
Now don't get me wrong, I totally understand different preferences, and if your current editor is e.g. TextMate/Sublime or an IDE like PhpStorm/Eclipse/Xcode, I can see it. But if you start with the premise that vim is the One True Editor, why would this be the switch reason, whereas IDEs before didn't get you there?
No problem with another flower in the garden of editing, I just thought the sales pitch was a bit weird.
Generally I wasn't really that impressed by the demo. Sure, the integration is nice, but I don't see how that's different from most other IDEs. But what struck me as a bit odd was the presenter stating a preference for vim, and then starting to edit Objective-C like all you've got is your cursor keys plus tab.
So, yes, another IDE, yay. And if you work at FB, sure, mindshare alone is probably worth it. But why would one give up normal mode/macros/elisp/abbrevs etc. for that?
Now don't get me wrong, I totally understand different preferences, and if your current editor is e.g. TextMate/Sublime or an IDE like PhpStorm/Eclipse/Xcode, I can see it. But if you start with the premise that vim is the One True Editor, why would this be the switch reason, whereas IDEs before didn't get you there?
No problem with another flower in the garden of editing, I just thought the sales pitch was a bit weird.
That's me in the video (hi!).
Re: pico. You'd be surprised what editors new employees and interns use when presented with a shell prompt :-D. At FB everyone is free to use their editor of choice...we don't force Nuclide on them.
Re: what's different. Xcode does Objective-C well. IntelliJ does Java well. PHPStorm does PHP well. Tons of editors do JS well. As soon as you start mixing technologies, the IDEs quickly degrade in overall usefulness and you basically have an IDE for one tech and a dumb text editor for the other. Nuclide is opinionated and provides a nice integrated end-to-end experience if you buy into the tech it supports. If you don't use any of that tech (Hack, react, buck, react native, flow, phabricator, mercurial, etc) or only use 1 language/platform at a time (like a pure objective-c iOS app) then Nuclide basically is Atom.
Nuclide's value is super apparent with React Native. You need to be able to edit JS and Objective-C and eventually Java, and it would be nice to have all the autocomplete/click-to-symbol/code search goodies for all three. Let alone debugging all of them and jumping between the stacks. No IDE provides all the features you need for a project like React Native out of the box. So we built one (leveraging Atom of course). It is magic working on a React Native app and using the same debugging UI to step through the JS, and then the Objective-C, and then using the SAME interface to debug your Hack code on the server.
Finally, over time you'll start to see a bunch of really, really smart integration with tools and libraries like Relay and GraphQL. We already have some internally--I can "click to definition" in a GraphQL query and see where it is defined in JS, and then click through and see where it is implemented in Hack on the server. Simple symbol search can't do that and spanning multiple languages and stacks is unsupported by most IDEs. Nuclide is opinionated so we can do deep integration like that...we leave the general editor-stuff to Atom proper.
Re: clumsy demo. I actually converted from vim when we started Nuclide...I even used vim for most of my JS/Android/Hack/iOS programming. For the demo I didn't install the vi bindings because I wanted fewer things that could go wrong. Because I wasn't a huge IDE user previously you see me using the mouse a ton instead of (generally) standard IDE keyboard shortcuts.
Re: pico. You'd be surprised what editors new employees and interns use when presented with a shell prompt :-D. At FB everyone is free to use their editor of choice...we don't force Nuclide on them.
Re: what's different. Xcode does Objective-C well. IntelliJ does Java well. PHPStorm does PHP well. Tons of editors do JS well. As soon as you start mixing technologies, the IDEs quickly degrade in overall usefulness and you basically have an IDE for one tech and a dumb text editor for the other. Nuclide is opinionated and provides a nice integrated end-to-end experience if you buy into the tech it supports. If you don't use any of that tech (Hack, react, buck, react native, flow, phabricator, mercurial, etc) or only use 1 language/platform at a time (like a pure objective-c iOS app) then Nuclide basically is Atom.
Nuclide's value is super apparent with React Native. You need to be able to edit JS and Objective-C and eventually Java, and it would be nice to have all the autocomplete/click-to-symbol/code search goodies for all three. Let alone debugging all of them and jumping between the stacks. No IDE provides all the features you need for a project like React Native out of the box. So we built one (leveraging Atom of course). It is magic working on a React Native app and using the same debugging UI to step through the JS, and then the Objective-C, and then using the SAME interface to debug your Hack code on the server.
Finally, over time you'll start to see a bunch of really, really smart integration with tools and libraries like Relay and GraphQL. We already have some internally--I can "click to definition" in a GraphQL query and see where it is defined in JS, and then click through and see where it is implemented in Hack on the server. Simple symbol search can't do that and spanning multiple languages and stacks is unsupported by most IDEs. Nuclide is opinionated so we can do deep integration like that...we leave the general editor-stuff to Atom proper.
Re: clumsy demo. I actually converted from vim when we started Nuclide...I even used vim for most of my JS/Android/Hack/iOS programming. For the demo I didn't install the vi bindings because I wanted fewer things that could go wrong. Because I wasn't a huge IDE user previously you see me using the mouse a ton instead of (generally) standard IDE keyboard shortcuts.
I guess that was intended as a vi-emacs joke/pun ...
Indeed. I guess I shouldn't quit my day job!
Seeing as how this is facebook's hacked up editor I'd love to see some more social features to share with other developers. Get advice, show something cool, share a branch, etc. with teammates or even the world.
I'm sure it is nice to have an editor that understands javascript better and it is nice to see that yes they have syntax checking and auto suggestion. Experience tells me the devil is in the details of the architecture for how much their integration will survive tool churn vs composition model of different tools.
What I'd really like to see in my next editor that seems hard to find is:
- Ability to easily share code and screen with other developers. I know the lone gun is typical in software development but it would be great to work with other people seamlessly as well.
- Working with files/shell on a remote server. All to often these days I find myself with large data set that is hard to move so I end up using console tools to debug the problem on the box.
I'm sure it is nice to have an editor that understands javascript better and it is nice to see that yes they have syntax checking and auto suggestion. Experience tells me the devil is in the details of the architecture for how much their integration will survive tool churn vs composition model of different tools.
What I'd really like to see in my next editor that seems hard to find is:
- Ability to easily share code and screen with other developers. I know the lone gun is typical in software development but it would be great to work with other people seamlessly as well.
- Working with files/shell on a remote server. All to often these days I find myself with large data set that is hard to move so I end up using console tools to debug the problem on the box.
I haven't used it, but https://floobits.com might scratch some of that itch?
Not nirvana, but not hell either — if you use vagrant — vagrant share + tmux + vim/emacs works well for remote pairing.
Did someone say Gavin Belson and Nucleus?
Yes! I made a graphic of it:
https://dl.dropboxusercontent.com/u/1000932/nuclide-eus.png
https://dl.dropboxusercontent.com/u/1000932/nuclide-eus.png
failure = success
Remote development sounds very interesting. If the IDE supports this directly, the user experience could be much better than the one you get when running an IDE over a remote desktop connection.
"Last but not least, this initial release includes our universal search tool package. In a large, multi-language codebase like ours, finding files and symbols quickly and efficiently is important for our engineers. Here's a glimpse:
SEARCHES INDEX.PHP"
sorry thought that was funny
sorry thought that was funny
You say "unified developer experience", I read "everybody will be forced to use the same tools". Not cool.
Strange/random observation: it is surprising that Chrome-style tabs seem to be the default tab representation given the pushback over the past few years over skeuomorphism in digital design.
This editor looks cool though. I haven't really looked at Atom, so I assume that it has good PHP/Python/Ruby support. I will try this out when it is released, I love the autocomplete
This editor looks cool though. I haven't really looked at Atom, so I assume that it has good PHP/Python/Ruby support. I will try this out when it is released, I love the autocomplete
I would go further—I'm confused by the proliferation of "tabs" as a UX metaphor. Do people really think they're the best thing they can get, compared to, say, ZUI zoomable groups?
They're great for browsers because the affordance fits: you have one active "browsing session", and then a bunch of inactive ones, and the inactive ones don't matter, and when you switch, you're asserting that the active one now doesn't matter.
But for productivity applications, tabs are just kind of silly.
In the OSX Finder, for example, if I have two windows open, I'm likely rearranging files between two-or-more folders—I need to see the state of both the source and the destination. You can drag-and-drop a file onto a tab, but you lose the visual cue as to where it's gone—it might have just ended up out of scroll-range in the current folder, or in some other random folder. To do the task quickly, I need to see both places: something done much better† by the window metaphor.
† (Though not perfectly: having to rearrange the windows to get the drag-sources and drop-targets all visible is a big hassle. Mac OS almost had something going for a while with MDI applications having their own virtual desktops, but they never far enough with it; if you could tell a given MDI application to auto-arrange/snap its document windows, people might actually start to want MDI interfaces again, rather than uberwindow "I know what's good for you" interfaces like FTP programs or Xcode.)
Then again, I'm also astounded that "tabs" aren't just a window manager feature (i.e. being able to group arbitrary windows into a single tabbed window, and noting when windows in a tab group spawn a new window and spawning it inside the tab group instead.) That would have cost too much GPU power decades ago, but it's costless with compositing window managers.
They're great for browsers because the affordance fits: you have one active "browsing session", and then a bunch of inactive ones, and the inactive ones don't matter, and when you switch, you're asserting that the active one now doesn't matter.
But for productivity applications, tabs are just kind of silly.
In the OSX Finder, for example, if I have two windows open, I'm likely rearranging files between two-or-more folders—I need to see the state of both the source and the destination. You can drag-and-drop a file onto a tab, but you lose the visual cue as to where it's gone—it might have just ended up out of scroll-range in the current folder, or in some other random folder. To do the task quickly, I need to see both places: something done much better† by the window metaphor.
† (Though not perfectly: having to rearrange the windows to get the drag-sources and drop-targets all visible is a big hassle. Mac OS almost had something going for a while with MDI applications having their own virtual desktops, but they never far enough with it; if you could tell a given MDI application to auto-arrange/snap its document windows, people might actually start to want MDI interfaces again, rather than uberwindow "I know what's good for you" interfaces like FTP programs or Xcode.)
Then again, I'm also astounded that "tabs" aren't just a window manager feature (i.e. being able to group arbitrary windows into a single tabbed window, and noting when windows in a tab group spawn a new window and spawning it inside the tab group instead.) That would have cost too much GPU power decades ago, but it's costless with compositing window managers.
> Then again, I'm also astounded that "tabs" aren't just a window manager feature (i.e. being able to group arbitrary windows into a single tabbed window, and noting when windows in a tab group spawn a new window and spawning it inside the tab group instead.) That would have cost too much GPU power decades ago, but it's costless with compositing window managers.
I'm trying to achieve this using i3 as window manager and a minimal browser like vimb which has no tabbing built-in. That way you can search for a browser page just like you would any other window.
I'm trying to achieve this using i3 as window manager and a minimal browser like vimb which has no tabbing built-in. That way you can search for a browser page just like you would any other window.
Kwin has this built-in, for the record.
Atom (and most other "tabbed" applications) isn't limited to just tabs-- it supports both multiple windows and arbitrary splitting inside a window. Tabs can be dragged and dropped freely between any pane. So, you can have tabs when it works well (IME, for the type of text editing one is doing while writing code, you're usually only actively using one file at a time, much like in a web browser), and you can have more than one file visible when you need that too.
(File management, on the other hand, is completely different; there, you're almost always going to want to have more than one thing visible and a windowed interface is better. That's why no mainstream file manager supports tabs OOTB.)
(File management, on the other hand, is completely different; there, you're almost always going to want to have more than one thing visible and a windowed interface is better. That's why no mainstream file manager supports tabs OOTB.)
I love OS X's exposé (app and all window). I have mine setup to be hot corners. I often drag a file to a corner and then drop it onto one of the exposé'd apps. I feel like I went back in time when I use OSes that doesn't support this functionality.
ZUI zoomable groups
ZUIs are far too esoteric for the average WIMP paradigm nearly all computer users are familiar with. I wouldn't count on it anymore than I would on getting an Oberon/Cedar-like programmable text window interface.
ZUIs are far too esoteric for the average WIMP paradigm nearly all computer users are familiar with. I wouldn't count on it anymore than I would on getting an Oberon/Cedar-like programmable text window interface.
Apple has been experimenting with zoomable UI a bit recently: the Apple Watch home screen is essentially a ZUI. On the iPhone, Photos and Calendar zoom as you progress through the levels of hierarchy (though you can't zoom interactively). Safari on the Mac and iPad also lets you zoom out to see your tabs in a ZUI-ish way.
That theme isn't the default anymore, now it's this https://github.com/atom/one-dark-ui.
Atom, Electron and this are all based on Chromium so why would it be surprising? Change for the sake of change or masking that their heritage isn't Google's Chromium?
Very promising. I wish there was more roadmap information. I cannot wait for the React and React Native parts to be released!
I'm a bit disappointed because of neither React or React Native were part of this release.
I think it is more communication and management of expectations than anything else. They opened the pre-release FB group, and not much was posted for weeks. This first release gives no clue as to when the React part will be available (other than "soon"). I cannot complain, or be disappointed, because they are sharing a great product for free. A roadmap with some estimated dates would really help keep the anxiety down :-)
I'm an alpha tester for Nuclide, and it's quite nice. There are a tonne of bugs that are getting ironed out, but it's brilliant to have an editor that is built for the stack I use: Hack, React and Flow. I use Atom as my daily editor along with Komodo, and I'm looking forward to Nuclide replacing both!
Previous discussion (273 points, 93 comments):
https://news.ycombinator.com/item?id=9273976
ES7 expertise? I thought ES6 was just finalized a few days ago.
ES7 was developed concurrently with ES6. ES6 is also officially known as ES2015 now with ES7 being referred to as ES2016. Apparently the goal is to ship functionality to the language on an annual basis.
Where do one keep up to date with the ES news? W3C mailing lists?
JavaScript Weekly is pretty good for that. http://javascriptweekly.com/
Why gate your progress on standards committees?
Not sure, but I think it's unique to JS b/c it's built into web browsers. Therefore, all major browsers vendors need to ok major changes to the language so that there isn't a severe fragmentation in version support. I think this is achieved via the standards committee.
The features they include are nice, but it would be really helpful to have dependency support for languages Scala and Java like IntelliJ does.
The neat part of being built on Atom, is that that is totally possible. There are already packages for handling the base language support for Java and Scala, linters for both of them, and through atom-ctags you can gain proper autocomplete.
Seems that Hack now has a first class IDE available, that the authors themselves can help contribute to, awesome.
[deleted](1)