3 ms·
Show HN: Fire.js: Visual Node.js Development with JSON, MongoDB and Cloudfoundry
- thepumpkin1979 15y agoAuthor here. I'm not a native english speaker, so I apologize if you you can understand some of the things I say. Slides available here: http://www.slideshare.net/thepumpkin/introduction-to-firejs-alpha http://www.slideshare.net/thepumpkin/introduction-to-firejs-... Any feedback will be highly appreciated :)
- nodesocket 15y agoLooks interesting, wish the video has been uploaded in HD, its a bit difficult to see.
- thepumpkin1979 15y agoThanks. About the HD, that's strange, I uploaded it in HD. http://vimeo.com/33211095 http://vimeo.com/33211095
- cosmic_shame 15y agoyou can only watch it in HD on vimeo
- thepumpkin1979 15y agointeresting, thanks. I edited the post to include this info.
- andreshb 15y agoAcabo de ver que eres de Barranquilla! Bueno saber que hay buenos hackers de node.js en Colombia :) Edit: o de venezuela? Igual, muy bien!
- thepumpkin1979 15y agoThanks Andres, I'm Venezuelan currently living in Colombia :)
- bprater 15y agoI'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?
- thepumpkin1979 15y agoyeah, 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? :)
- jimrhoskins 15y agoI 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.
- thepumpkin1979 15y agoMakes 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 :)
- thepumpkin1979 15y agoLet me give you an example from the IDE source code, Check this expression: https://github.com/firejs/fire-ide/blob/master/FireIde.Core.Package.Load.fjson 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.
- jimrhoskins 15y agoCool, 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.
- deleted 15y ago[deleted]
- thepumpkin1979 15y agoThanks, 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. 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 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 :)
- mhseiden 15y agoThis, 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".