
IDE for building React Native apps is now free and open source - somecoder
https://www.decosoftware.com/may-2016-update
======
dang
[https://news.ycombinator.com/item?id=11771697](https://news.ycombinator.com/item?id=11771697)

------
mythz
Wow this is the best iterative development I've seen for iOS and easiest way
I've seen to get started with React Native.

Enabling Hot Reloading (w/ Ctrl+D) lets you see changes as you type, you don't
even need to hit Save. If this is a sign to come from React Native, it's going
to be a game changer for both iterative development experience and code-reuse
between iOS/Android.

My only concern is that I don't see how an IDE not developed in partnership
with Facebook is going to succeed as I'd expect it to always be playing
catchup with new features. Maybe it would've been better as a series of Atom
plugin enhancements on top of Facebook's
[https://nuclide.io](https://nuclide.io)

~~~
kcorbitt
> My only concern is that I don't see how an IDE not developed in partnership
> with Facebook is going to succeed as I'd expect it to always be playing
> catchup with new features.

New features for React Native are extensively discussed on the github repo and
in the Facebook contributors' group before making it into a release. And at
this point, a substantial minority of features are proposed, implemented and
sometimes even merged by non-Facebook contributors. It takes a lot of work to
stay on top of all the changes of course, but being developed outside of
Facebook shouldn't make that process harder than it would be anyway.

~~~
mythz
Being an independent project is presumably going to have less dev resources
than Facebook, as a non-official IDE they're also going to have a smaller
ecosystem and not having direct access or influence with the core React Native
development team is a disadvantage for Facebook tooling developers who would.

Whilst it's not impossible to compete with official tooling, they'll always be
faced with a distinct disadvantage where they'd need to deliver a lot of added
value in order to attract relevant mindshare.

------
api
So pretty soon we'll have cross platform UI development again, including
eventually Mac and Windows once React Native is ported there. (Windows is I
think already in beta somewhere.)

If we can bring in the web again via React Native for the Web (with 'widgets')
then we can have UI "everywhere" with a mostly common code base.

I feel like eventually we are going to really converge. It's going to take a
while before it's pretty and seamless and performant, but I feel like we'll
eventually get there. The benefits are just too massive for it not to happen,
especially for smaller projects that don't have a budget to have six dev teams
maintain six UI code bases.

------
ed312
Why use an IDE focused on React Native vs a generalist one with React support?

~~~
evo_9
"What is Deco? Deco is an IDE for React Native. It's an all-in-one solution
for writing React Native apps that you can download and use without any
environment setup. Deco improves the React Native development workflow by
focusing on component reuse and enabling you to edit your UI in real time."

------
ihsw
Many are starting to use GitHub as a registry for hosting packages, in this
case Deco components[1].

GitHub should look into this, otherwise we get git repos with directories that
are thousands in length.

Certainly it makes sense to host published code on GitHub as well as in-
development code.

I could see it replacing the likes of NPM[2], Packagist[3], RubyGems[4],
PyPI[5], etc.

[1] [https://github.com/decosoftware/deco-
components/tree/master/...](https://github.com/decosoftware/deco-
components/tree/master/.deco)

[2] [https://www.npmjs.com/](https://www.npmjs.com/)

[3] [https://packagist.org/](https://packagist.org/)

[4] [https://rubygems.org/](https://rubygems.org/)

[5] [https://pypi.python.org/pypi](https://pypi.python.org/pypi)

~~~
jswny
This could work. There wouldn't be a need anymore for linking to the Git repo
in an NPM package or similar. Maybe a special branch with a simple JSON file
containing package data in the same repo as the main project.

~~~
ihsw
Versioning and indexing becomes an issue -- this has to be entirely and
completely separate from git repos and git branches. Playing with branches
like that falls apart pretty quickly when you need to add real features that
are expected by package maintainers.

------
traviswingo
Who here uses this? I'd love some real-world feedback on your experience. It
looks awesome.

------
_puk
This looks awesome - even has pretty documentation!

Have run the tutorial without issue, took only a couple of minutes.

There seems to be only a small number of Components available out the box,
with new ones accepted via PR.

This works fine for now, but it would be great if I could import my own
Components or even build new ones within the UI.

I'd like to be able to "View Source" on a Component, it's obviously available
via GitHub, but that's a few more clicks away.

Does anyone know of any similar IDE for desktop React?

------
shujito
Is it only for OS X?

~~~
supergreg
It seems to be built on electron (atom?) so it shouldn't be difficult to port
to other platforms.

~~~
_puk
It uses the iOS simulator, so that's likely the hard bit to port.

Just noticed it doesn't provide the option for Android simulation, which would
be more portable.

------
adamnemecek
Is this only for React Native and not web React?

~~~
pbreit
Yeah, I'm trying to figure out how React and React Native relate. Are they
similar enough that a React app can be modified to "go native" fairly easily?
Like let's say you were building Slack which has web and desktop apps that
appear identical. Could/would you use React/React-Native and this IDE?

~~~
leoalves
Most of the logic can be the same. But the UI is different. For the web it
uses html elements and for native uses native ios/android elements. Even
android and ios are different. That's the biggest advantage if compared to
Adobe Cordova. A lot more performant

~~~
jjnoakes
It isn't about whether the underlying ui is different or not. Of course it is.

It is about whether the source application code can be the same. Today it
isn't. But why not create a set of source compatible components that render to
Android, iOS, and HTML?

I've seen projects approach this and I think it is a good idea. You get the
typical lowest-common-denominator problem but if you have a decent way to mix
in platform-specific elements where required, what is the downside?

