Show HN: Fire.js: Visual Node.js Development with JSON, MongoDB and Cloudfoundry(firejs.firebase.co)
firejs.firebase.co
Show HN: Fire.js: Visual Node.js Development with JSON, MongoDB and Cloudfoundry
http://firejs.firebase.co/post/13823060173/this-is-an-introductory-video-to-the-basic
5 comments
[deleted](1)
Acabo de ver que eres de Barranquilla! Bueno saber que hay buenos hackers de node.js en Colombia :)
Edit: o de venezuela? Igual, muy bien!
Edit: o de venezuela? Igual, muy bien!
Thanks Andres, I'm Venezuelan currently living in Colombia :)
Looks interesting, wish the video has been uploaded in HD, its a bit difficult to see.
Thanks. About the HD, that's strange, I uploaded it in HD. http://vimeo.com/33211095
you can only watch it in HD on vimeo
interesting, thanks. I edited the post to include this info.
This, in concept, really epitomizes an unfortunate trend towards making programming and development "easier" and "more accessible".
As I see it, this is no longer "Node.js, JSON, MongoDB, and Cloudfoundry". It certainly uses all of those technologies, but in reality, you are learning "Fire.js".
Even with a polished version, it doesn't seem like a developer would ever learn how to use the underlying technologies in an expressive, applicable manner. It just comes off as another excuse for developers to side-step learning about and getting into "the thick of it".
As I see it, this is no longer "Node.js, JSON, MongoDB, and Cloudfoundry". It certainly uses all of those technologies, but in reality, you are learning "Fire.js".
Even with a polished version, it doesn't seem like a developer would ever learn how to use the underlying technologies in an expressive, applicable manner. It just comes off as another excuse for developers to side-step learning about and getting into "the thick of it".
I'm seeing zero information on what this software does, even when quickly scanning the homepage -- therefore, I'm hardly ready to commit 15 minutes to watching a video. What is Fire.js?
yeah, sorry about that, I guess I didn't spend enough time to create a landing page or something. If you want to give it another try, can you jump to minute 10:58? :)
I only watched the first few minutes of the video, then skipped around. What is the benefit of fire, as a framework? Can you work without the Fire IDE, and would that be worth it?
I just can't see giving up my text editor to click around a web interface to write code. It just seems orders of magnitude slower to me.
It looks cool and I appreciate the effort, I just have a hard time figuring out the benefit of fire to me as a developer.
I just can't see giving up my text editor to click around a web interface to write code. It just seems orders of magnitude slower to me.
It looks cool and I appreciate the effort, I just have a hard time figuring out the benefit of fire to me as a developer.
Makes sense, I guess I didn't focused the video to explain what it solves, my bad. Well the goal is to make it easy the development of Node.js application when you work with a lot of asynchronous operations, which turns to be like 90% of the work you do in Node.js. Because Node.js works in a asynchronous way, so you have to write a lot of callbacks to work with the results when they are available, Fire.js uses JSON documents to define the behavior you'd have to write in plain javascript. With fire.js you don't have to write callbacks, just put expression calls in a JSON block one after the other.
{ "@DoThis": null, "@ThenDoThat":null }
Under the hood everything will be async.
If you want to give it another try, load the video at minute 10:58 and I will try to explain what it does and how it does it :)
{ "@DoThis": null, "@ThenDoThat":null }
Under the hood everything will be async.
If you want to give it another try, load the video at minute 10:58 and I will try to explain what it does and how it does it :)
Cool, thanks for the tip, I watched the video. It looks like you're doing some cool stuff, but it doesn't look appealing to me as a developer who is already comfortable with node.
The biggest mental leap for me is that you are using JSON objects to define sequential code. JSON defines an object as unordered. Obviously your compiler maintains order properly, however it just "feels wrong".
Like I said there is no way you can convince me to write code in a browser (unless there is an absolutely magical benefit), so writing fjson manually looks difficult both in the amount of extra syntax, as well as trying to connect the data to what it's doing.
The last thing that would hold me back is the debugging experience. Will i get back which lines im my documents are causing runtime errors, is there any static checking in place to make sure the strings of code are syntactically correct?
It's a big leap for me, but that being said, I definitely applaud you for developing something new and experimenting. I'm interested in seeing where this evolves.
The biggest mental leap for me is that you are using JSON objects to define sequential code. JSON defines an object as unordered. Obviously your compiler maintains order properly, however it just "feels wrong".
Like I said there is no way you can convince me to write code in a browser (unless there is an absolutely magical benefit), so writing fjson manually looks difficult both in the amount of extra syntax, as well as trying to connect the data to what it's doing.
The last thing that would hold me back is the debugging experience. Will i get back which lines im my documents are causing runtime errors, is there any static checking in place to make sure the strings of code are syntactically correct?
It's a big leap for me, but that being said, I definitely applaud you for developing something new and experimenting. I'm interested in seeing where this evolves.
Thanks. I understand you perfectly, in fact, JSONScript is not a replacement for Javascript, it just make it easy to develop server side API's without having to dealing with Javascript. I found it perfectly suitable for those Android and iOS developers that have to use persistence services like parse.com or stackmob.com just to persist simple server side data. As the number of ignitable modules(node.js modules designed to be used by the fire.js Runtime) grow up, then less javascript those developers have to write.
I'm also improving the error reporting for the stable version, it's kinda hard to figure out where the error occurred in this alpha version.
btw, you can develop without the IDE, there is a command line utility called 'firejs' that you can use to launch the apps. If you want to know more, check the tutorials. https://github.com/firejs/fire/wiki/Tutorials
Thanks for your comment jim :)
I'm also improving the error reporting for the stable version, it's kinda hard to figure out where the error occurred in this alpha version.
btw, you can develop without the IDE, there is a command line utility called 'firejs' that you can use to launch the apps. If you want to know more, check the tutorials. https://github.com/firejs/fire/wiki/Tutorials
Thanks for your comment jim :)
Let me give you an example from the IDE source code, Check this expression: https://github.com/firejs/fire-ide/blob/master/FireIde.Core....
You will see how I check if the file "package.json" exists, if it exists then I parse the content of the file. If it doesn't exists then I return false.
Because I didn't use javascript then I didn't have to write any callbacks to achieve the behavior. It's a lot simplier with JSONScript.
You will see how I check if the file "package.json" exists, if it exists then I parse the content of the file. If it doesn't exists then I return false.
Because I didn't use javascript then I didn't have to write any callbacks to achieve the behavior. It's a lot simplier with JSONScript.
Any feedback will be highly appreciated :)