5 ms·
Since we're talking about node... I like async, and I like node. However, for plain jane dynamic web apps, with no real time needs, I see it as being more of p
by andrewvc 16y ago
Since we're talking about node...
I like async, and I like node. However, for plain jane dynamic web apps, with no real time needs, I see it as being more of pain than using Ruby (or Python, or whatever).
Why? JS syntax kinda sucks for dealing with day to day business logic. Ruby is just more clear and easier to work with.
I think using node.js by default is bad design. It should be isolated to the cases where you need it.
- FlemishBeeCycle 16y agoIf you find the syntax to be a problem - you may find CoffeeScript (http://coffeescript.org/ http://coffeescript.org/) interesting. It emphasizes the good parts of JavaScript while minimizing the warts, all wrapped up in very nice syntax.
- jashkenas 16y agoHere's a fun example. Matz (creator of Ruby) contributed a chapter to Beautiful Code (the O'Reilly book). In it, he uses this example of a Rake task as his example of a beautiful piece of Ruby: task :default => [:test] task :test do ruby "test/unittest.rb" end Let's see what that could look like in CoffeeScript, assuming a similar library: task default: ['test'] task 'test', -> ruby 'test/unittest.rb' Pretty nice. Running that through the CoffeeScript compiler produces this JavaScript: task({ "default": ['test'] }); task('test', function() { return ruby('test/unittest.rb'); });
- rbxbx 16y agohttp://coffeescript-theparts.heroku.com/ http://coffeescript-theparts.heroku.com/ this could be of interest, although the actual coffeescript site is better/great...
- weixiyen 16y agoI don't think syntax is really that much of an issue. The fact is if you might expand to real-time apps later on, you'll have to write new abstractions all over again for stuff like fetching data, whereas if you started with something like node.js, you wouldn't. It's simply a matter of if you feel it's worth it or not, and it's really case-by-case.
- wallfly 16y agoI posted this info as a comment on the guy's blog (still awaiting moderation), but I thought you might find it interesting too, the point being that amazing things are possible with JavaScript and node.js, but if you're thinking single-file scripts with a tangled nest of callbacks and prototypal inheritance chains+constructors that are hard to keep straight, well ... there are better ways ......... :-D As a JavaScript developer working with node.js (and client side scripts too, of course), I’d like to recommend a couple of related things: Joose3 — an object system for JavaScript which allows truly classful programming; use it to implement all sorts of meta-programming magic with ease: http://joose.it/ http://joose.it/ http://openjsan.org/doc/s/sa/samuraijack/Joose/3.011/lib/Joose.html http://openjsan.org/doc/s/sa/samuraijack/Joose/3.011/lib/Joo... JooseX.CPS — a continuation-passing-style "trait" for Joose classes which helps prevent your asynchronous code from turning into "callback spaghetti": http://joose.it/blog/2010/08/02/asynchronous-aka-non-blocking-control-flow/ http://joose.it/blog/2010/08/02/asynchronous-aka-non-blockin... http://openjsan.org/doc/s/sa/samuraijack/JooseX/CPS/0.11/lib/JooseX/CPS.html http://openjsan.org/doc/s/sa/samuraijack/JooseX/CPS/0.11/lib... Joose is open source, works with both node.js and in browsers, and there are various ways to install and leverage its libraries, e.g. npm: http://github.com/isaacs/npm http://github.com/isaacs/npm This isn’t an advertisement. I started exploring node.js in early 2010, and my "discovering" Joose was a real boon as I was looking to do some complicated things that seemed daunting when trying to express the concepts in terms of prototypal inheritance. Not everyone finds it attractive, but I’m always happy to spread the word in hopes that Joose can make someone else’s life and programming projects a little less stressful, which is what it's done for me.