Did someone say Gavin Belson and Nucleus?
Was the first thing that came to my mind when I saw the title :)
Yep, that's the first thing that came to mind for me too - not sure why they chose to keep it.
Building Nuclide, a unified developer experience
41–50 of 77 posts
Re: Building Nuclide, a unified developer experience
#42The features they include are nice, but it would be really helpful to have dependency support for languages Scala and Java like IntelliJ does.
Re: Building Nuclide, a unified developer experience
#43Strange/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
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.
Re: Building Nuclide, a unified developer experience
#44Strange/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
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 mat…
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.
Re: Building Nuclide, a unified developer experience
#45Why 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.
Re: Building Nuclide, a unified developer experience
#46Earlier quoted context omitted.
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.
>is that it would be easier to bring Emacs/VIM up to acceptable GUI editor standards
Perhaps but nobody has done it yet.
Re: Building Nuclide, a unified developer experience
#47Why 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.
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.
Re: Building Nuclide, a unified developer experience
#48"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
Re: Building Nuclide, a unified developer experience
#49Strange/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
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 mat…
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.
Re: Building Nuclide, a unified developer experience
#50Seeing 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.