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.
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 :)
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.
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.
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, and yeah, I still have to do a lot of work. yes it is slower because I haven't optimized the UI to work with VIM-like navigation, but yes, you are right about the mouse and the UX, it's better to keep the hands on the keyboard most of time while you are coding. About the debugging, is not that hard as you may think, I've designed the runtime with debugging in mind from the very beginning, it's a lot of work but is not impossible at all.
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".
17 comments
[ 3.4 ms ] story [ 43.3 ms ] threadAny feedback will be highly appreciated :)
Edit: o de venezuela? Igual, muy bien!
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.
{ "@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 :)
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.
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.
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 :)
About the scopes, I don't know if this entry in the wiki is the answer to your question, want to check it out? https://github.com/firejs/fire/wiki/Variables-and-Paths Jump to the "scopes" section.
I still have 4 months left for what I think it's gonna be the first stable release :)
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".