13 ms·

IDE for building React Native apps is now free and open source

202 points by somecoder 10y ago

shujito 10y ago
Is it only for OS X?
- RussianCow 10y ago
  Yep. The GitHub readme says Windows and Linux are not supported at this time.
- _puk 10y ago
  From the readme [0], yep, only Mac is supported at this time 0: https://github.com/decosoftware/deco-ide/blob/master/README.md https://github.com/decosoftware/deco-ide/blob/master/README....
- supergreg 10y ago
  It seems to be built on electron (atom?) so it shouldn't be difficult to port to other platforms.
  - _puk 10y ago
    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.
traviswingo 10y ago
Who here uses this? I'd love some real-world feedback on your experience. It looks awesome.
deleted 10y ago
[deleted]
_puk 10y ago
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?
ihsw 10y ago
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/.deco https://github.com/decosoftware/deco-components/tree/master/... [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 10y ago
  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 10y ago
    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.
- consolelog 10y ago
  http://bower.io/ http://bower.io/ does this in a sense by watching releases on a repository.
- pierrec 10y ago
  >GitHub should look into this, otherwise we get git repos with directories that are thousands in length. In a way, Github already looked into it extensively while helping resolve the issue where CocoaPods monopolized their servers and hit CPU rate-limiting. Whether it's abusive or not was already debated ad nauseum when it happened, but either way they came to a set of solutions which might help anyone else wanting to use Github for package management: http://blog.cocoapods.org/Master-Spec-Repo-Rate-Limiting-Post-Mortem/ http://blog.cocoapods.org/Master-Spec-Repo-Rate-Limiting-Pos...
adamnemecek 10y ago
Is this only for React Native and not web React?
- pbreit 10y ago
  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?
  - afontaine 10y ago
    From what I understand, you can't just "go native" from ReactJS because React Native uses specific components for mobile. While you can't just port over, the way you think about components and your API endpoints can be re-used. It's also nice that they both work with components which allows for less "context switching."
  - leoalves 10y ago
    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 10y ago
      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?
  - grayrest 10y ago
    They're using the same core library and conceptually work the same way but there's no no out-of-the-box unified widgets allowing you to share view code between both. So you can share your controllers, model, viewmodel, and higher order data binding components but you'll be rewriting your views.
ed312 10y ago
Why use an IDE focused on React Native vs a generalist one with React support?
- evo_9 10y ago
  "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."
mythz 10y ago
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
- kevinqi 10y ago
  yeah, dragging components from the component list and seeing them immediately reflected in the simulator with live-reload is freaking awesome.
- kcorbitt 10y ago
  > 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 10y ago
    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 10y ago
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.
dang 10y ago
https://news.ycombinator.com/item?id=11771697 https://news.ycombinator.com/item?id=11771697
deleted 10y ago
[deleted]

202 points by somecoder 10y ago

shujito 10y ago

Is it only for OS X?

RussianCow 10y ago
Yep. The GitHub readme says Windows and Linux are not supported at this time.
_puk 10y ago
From the readme [0], yep, only Mac is supported at this time 0: https://github.com/decosoftware/deco-ide/blob/master/README.md https://github.com/decosoftware/deco-ide/blob/master/README....
supergreg 10y ago
It seems to be built on electron (atom?) so it shouldn't be difficult to port to other platforms.
- _puk 10y ago
  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.

traviswingo 10y ago

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

deleted 10y ago

[deleted]

_puk 10y ago

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?

ihsw 10y ago

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/.deco https://github.com/decosoftware/deco-components/tree/master/... [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 10y ago
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 10y ago
  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.
consolelog 10y ago
http://bower.io/ http://bower.io/ does this in a sense by watching releases on a repository.
pierrec 10y ago
>GitHub should look into this, otherwise we get git repos with directories that are thousands in length. In a way, Github already looked into it extensively while helping resolve the issue where CocoaPods monopolized their servers and hit CPU rate-limiting. Whether it's abusive or not was already debated ad nauseum when it happened, but either way they came to a set of solutions which might help anyone else wanting to use Github for package management: http://blog.cocoapods.org/Master-Spec-Repo-Rate-Limiting-Post-Mortem/ http://blog.cocoapods.org/Master-Spec-Repo-Rate-Limiting-Pos...

adamnemecek 10y ago

Is this only for React Native and not web React?

pbreit 10y ago
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?
- afontaine 10y ago
  From what I understand, you can't just "go native" from ReactJS because React Native uses specific components for mobile. While you can't just port over, the way you think about components and your API endpoints can be re-used. It's also nice that they both work with components which allows for less "context switching."
- leoalves 10y ago
  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 10y ago
    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?
- grayrest 10y ago
  They're using the same core library and conceptually work the same way but there's no no out-of-the-box unified widgets allowing you to share view code between both. So you can share your controllers, model, viewmodel, and higher order data binding components but you'll be rewriting your views.

ed312 10y ago

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

evo_9 10y ago
"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."

mythz 10y ago

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

kevinqi 10y ago
yeah, dragging components from the component list and seeing them immediately reflected in the simulator with live-reload is freaking awesome.
kcorbitt 10y ago
> 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 10y ago
  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 10y ago

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.

dang 10y ago

https://news.ycombinator.com/item?id=11771697 https://news.ycombinator.com/item?id=11771697

deleted 10y ago

[deleted]