Well, I see no point in using Long Path Tool or any other paid app when my workflow already includes Node.js and there's a free and faster command-line alternative in the ecosystem.
Too much spam in Coderwall comments lately :-(...
@f0ru0l0rd - Hi David, thanks for reading. Actually we're not in any kind of disagreement. It's been 18 months since I wrote the article above and some things have changed. Some big corporations are now indeed using Node.js, some are - at least - acknowledging its presence and displaying its logo on their websites... :-)
Thanks for reading, @markpanado - the Sublime Text theme is Soda Dark, developed by Ian Hill. I like dark themes, but I find most of them too sharp on the eyes. I think Soda Dark is the only one achieving perfect balance between ellegance and readability.
I also think Soda Dark works best with tomorrow color scheme. Both of them can be installed with Sublime Package Manager.
As a side note, IMHO the Soda Dark + Tomorrow combination is what Microsoft UX guys should have copied for Visual Studio 2013, instead of simply jumping into the dark UI bandwagon just because it was trendy ;-)...
One more thing - thanks to Alin Andrei from WebUpd8, you can now use Atom in Ubuntu 14.04...
Totally agree with you, Piotr!...
Ideally, I prefer working on a 27" iMac; I have to admit Apple does offer the best ergonomics money can buy: lots of screen real-estate (a pleasure to make use of livereload), Apple's wired keyboard is fantastic (I hate their mice, though)... and one can use Sketch + Pixelmator instead of Photoshop + Illustrator.
But since they are so damn expensive, for the rare occasions when I have to be mobile, I decided to go for an Acer V5 with Ubuntu 14.04. Since I mostly do web development with Node.js and I like to automate some of my tasks with bash scripts, Windows 8 really wasn't an option.
There are few things I really miss in Ubuntu; the absence of a real vector-based design solution (like Sketch on Mac) is the only real big pain. Inkscape is good and becoming better, but nowhere near Sketch, and its unnatural 0y axis direction is kind of a show-stopper for web mockups...
@manuite - if you like MongoHub, just make sure to use FotoNauts' fork, as the original project is no longer maintained...
Nice, and nicely written!
I forgot to mention I'm also using socket.io for real-time synchronisation between team members...
@dansabin - haven't got much time to experiment, but adding a CSS transition: background-position 1s
on the <div class="hero">
element might work.
But the whole adjustment + transition might be a bit CPU/GPU intensive, especially for mobile devices, which is why the scroll
event handler should probably be debounced.
If I remember correctly, I've noticed the animation on interiordelight.ro was initially a bit jerky on Android/iOS, and I think I've tried doing just that for mobile devices...
@designbyonyx You're welcome, Ryan!
I haven't used web sockets yet in my apps and I know people were complaining about it on Heroku, but I understood they fixed it in late 2013. See this stackoverflow thread here, the guy has a basic example running on Heroku.
Also, heroku run bash
will give you console access.
Due to a bug in recent NPM versions, this doesn't work anymore, but you can use this hack instead.
@dpashkevich - yes, a change in behaviour is always a possibility. Restricting it, I don't know about that... I don't see why would they do that. Besides, this is exactly how they're using it on Google+ itself.
@dpashkevich - true :-).
It happened before with Buzz... That's why I said "if you decide to use it you'll do it on your own responsibility and I'd suggest keeping an eye on everything since they might change this behaviour at some point" :-)
On the other hand, Google+ seems to do well and it's still gaining momentum as we speak...
@designbyonyx - thank you for reading my post, Ryan!
In relation to hosting infrastructure, I've tried Heroku, AppFog and I've played around a bit with OpenShift.
Each one has its own pros and cons, but I can safely say my number one favourite is Heroku by far. Not the cheapest, but it's safe, reliable, you can run any Node.js version you like, it has a nice git-based deployment mechanism with the possibility to do rollbacks if necessary, and you can also choose among an infinity of add-ons for your apps. Plus, their now standard Node.js buildpack has a fantastic caching mechanism that will only download and install the necessary NPMs in your server environment (which means really fast deployments).
I'm not sure I understand what you mean by tips on "installing node modules". If they're on npmjs or github, Heroku will install them automatically based on package.json
. But on most PaaS providers you can deploy your node_modules
folder anyway. If your modules use native code, they might have to be compiled on the deployment environment, but again most PaaS deployment mechanisms will do it behind-the-scenes based on node-gyp
.
If we're talking about "standard" web projects (tens to hundreds of concurrent users), there aren't many things you can't do with clustering and 1-2 Heroku web workers. For larger projects, scaling is pretty straightforward, but it also depends on your app architecture.
In relation to MongoDB, I like both MongoLab and MongoHQ.
RedHat's OpenShift is also interesting as a "general purpose" PaaS provider, you can do lots of things with it, but you'll have to do a bit of command-line hacking and configuration if you want to install a particular Node.js version for instance. But they do offer you 3 free boxes to start with...
If you liked this tip, you might also be interested in a quick and dirty fix for the infamous Safari blank-page bug.
If you liked this tip, you might also be interested in how to use dynamically resized-images from Google+ on your websites.
...and a 2nd one about a quick & dirty fix for the infamous Safari blank-page bug
Here's the first tip: Using dynamically resized-images from Google+
@bazineta - I'm just curious, why would you want to merge those fields?
@pavelnikolov - you'll definitely have to implement your own logic for that... It's probably fairly easy to do if you're using passport.
@mahnunchik - combining "full power of Grunt" with the "simple and predictable syntax" of ASPAX is an excellent idea.
Don't forget that you can also grunt.util.spawn
aspax CLI in your scenario!
@mahnunchik - my thoughts exactly, but I usually have to perform multiple/mixed actions on my assets.
I was trying to switch to Grunt when I first came across it a few months ago, but didn't really like the idea of having to write so much code. Here's a "real-life" sample aspax.yml
:
js/index.js:
- lib/swiper/idangerous.swiper-2.3.js
- lib/moment/moment.js
- lib/moment/lang/ro.js
- lib/jquery.unveil.js
- scripts/public/jquery.lsh.coffee | bare
- scripts/public/common.coffee | bare
- scripts/public/main-gallery.coffee | bare
- scripts/public/product.coffee | bare
- scripts/public/search-form.coffee | bare
- scripts/public/contact-form.coffee | bare
js/admin.js:
- lib/underscore.string.js
- lib/jquery.ui.core.js
- lib/jquery.ui.widget.js
- lib/jquery.ui.mouse.js
- lib/jquery.ui.sortable.js
- lib/jquery.iframe-transport.js
- lib/jquery.fileupload.js
- lib/jquery.autosize.js
- scripts/admin/jquery.lsh.admin.coffee | bare
- scripts/admin/user-list.coffee | bare
- scripts/admin/dealer-list.coffee | bare
- scripts/admin/make-list.coffee | bare
- scripts/admin/meta-model-list.coffee | bare
- scripts/admin/model-list.coffee | bare
- scripts/admin/attribute-list.coffee | bare
- scripts/admin/product-edit.coffee | bare
- lib/jade-runtime.js
- templates/namespace.coffee | bare
- templates/user-edit.jade
- templates/dealer-edit.jade
- templates/make-edit.jade
- templates/meta-model-edit.jade
- templates/model-edit.jade
- templates/attribute-edit.jade
css/index.css:
- lib/icomoon/style.css
- lib/swiper/idangerous.swiper.css
- styles/index.styl | nib
css/admin.css:
- styles/admin.styl | nib
css/product-print.css:
- styles/product-print.styl | nib
images/logo.png | fp : images/logo.png
images/logo@2x.png | fp : images/logo@2x.png
images/carbon-texture.png | fp : images/carbon-texture.png
images/carbon-texture@2x.png | fp : images/carbon-texture@2x.png
images/carbon-texture-light.png | fp : images/carbon-texture-light.png
images/carbon-texture-light@2x.png | fp : images/carbon-texture-light@2x.png
images/barcode.png | fp : images/barcode.png
images/barcode@2x.png | fp : images/barcode@2x.png
images/breadcrumbs-separator.png | fp : images/breadcrumbs-separator.png
images/breadcrumbs-separator@2x.png | fp : images/breadcrumbs-separator@2x.png
images/spinner-140x105.gif | fp : images/spinner-140x105.gif
favicon.png : icons/favicon.png
apple-touch-icon-57x57-precomposed.png : icons/apple-touch-icon-57x57-precomposed.png
apple-touch-icon-72x72-precomposed.png : icons/apple-touch-icon-72x72-precomposed.png
apple-touch-icon-114x114-precomposed.png : icons/apple-touch-icon-114x114-precomposed.png
apple-touch-icon-144x144-precomposed.png : icons/apple-touch-icon-144x144-precomposed.png
fonts/im.eot | fp : lib/icomoon/fonts/icomoon.eot
fonts/im.svg | fp : lib/icomoon/fonts/icomoon.svg
fonts/im.ttf | fp : lib/icomoon/fonts/icomoon.ttf
fonts/im.woff | fp : lib/icomoon/fontsfonts/icomoon.woff
Can you imagine the trouble of writing a Grunt scenario for that thing?...
@mahnunchik - Sprockets has years of development behind and a well-deserved place in RoR world. Can't really hope to achieve the same with ASPAX :-)
Leaving the joke aside, I'm not sure there's room for something so complex, complete and well-established as Sprockets in the Node.js world. The ecosystem is much more dynamic than Ruby/RoR, things are changing really fast, Harmony is closing in, a new frameworks will soon become the de-facto standard for a while...
Personally, I'd rather keep ASPAX codebase as simple as possible and choose to focus on plugin development. So, if you have an idea...
@sagish - a Gruntfile.js
vs. aspax.yml
comparison, as promised :-P
Hi @mahnunchik, thanks a lot for your feedback! Yes, it makes sense to carry on this discussion on GitHub. I'll just mention here that St does look good, which means we could probably drop the compression feature entirely from ASPAX.
Jonah Ruiz is also interested in contributing to ASPAX, so let's see what we can do :-)
Nice!
Nice, it's good to remember one can use ImageMagick utilities even for PSD files.
Thanks for sharing!
Hi @mahnunchik,
Thanks a lot for your feedback!
Just a few quick comments on your questions/remarks:
About using hash fingerprints to avoid unnecessary cache busting - yes, that's a very good idea, I thought about it but couldn't come up with a clean and elegant solution. It would be kind of complicated to implement, since ASPAX is also replacing asset URLs in CSS files where needed. Please have a look at the code and if you can come up with a solution, I'm open.
Executing non-js files (ICS in this case) - this has already been addressed in CoffeeScript here and ported to IcedCoffeeScript 1.6.3-j, that's why I'm using
require('iced-coffee-script/register')
.Compression with ASPAX vs. server compression - yes, it can be done with compress or a static server, but as far as I remember there's no caching mecanism behind the "standard" compress connect-middleware. So I see no reason why it shouldn't be done just once before deployment, especially since all contemporary browsers suport gzip.
I see this feature useful for (let's say small) projects deployed on PaaS providers like Heroku or OpenShift without using a separate server (i.e. nginx) or a CDN for static assets.
I'm not sure I follow you on what ASPAX should do for small vs. medium or large projects, though...
Hi @sagish,
Thank you for reading!
I'm planning to do a Gruntfile.js
vs. aspax.yml
comparison soon and I'll let you know about it :-)
Nice! I almost forgot about npm version
, thanks for sharing :-)
The --depth=0
parameter also works for npm outdated
...
@leecrossley thanks for pointing that out!
It's also worth saying that one could add something like this in his .profile
in order to save typing:
alias npml="npm list --depth=0 "$@" 2>/dev/null"
Thank you all for reading and for your comments!
@nemoden - I don't have an advertising department, but when I'll do, I'll make sure to teach the girls some post-processing effects :-P. Actually it is a screenshot, with a perspective effect. Some people like it, some hate it, but in the end more people tend to notice/remember those :-)...
As you probably know already, in Node.js modules are cached. So if you require
the same module in multiple files across your application, it won't get loaded multiple times and it won't take more memory.
However, I believe it's always a good practice - and I try to stick to it - to only require the modules you need. Adding libraries which you "may or may not use" will certainly increase the memory footprint and deployment size. I mean, Node.js apps have the potential to be fast and lean, but one could easily turn them into sluggish and bulky by require
ing the whole npm registry :-)
For instance, I was using mysql
, cli-color
and commander
during development/deployment and legacy-data importing phase in a recent project. Those modules weren't necessary in production, so I added them in devDevelopment
section of package.json
, but they were still being deployed to Heroku, so I had to specifically add them to .slugignore
. As a result, the slug size went down from 20 MB to 16 MB.
So I'd say there's no generic answer to your question; the only way to actually know is testing...
@jensanity5000 :-) Thanks for reading, Adam!
Yes, displaying date/time/numbers in human-readable formats is one of the possible benefits. I also use the same approach for stuff like capitalization, building sentences from arrays, etc.
You can even define your own "formatting" library and make it available to jade templates in the same way for more complex tasks...
Good thing to remember :-)
@mattyw - Thanks for reading and sharing your thoughts :-)
@emmenko - Thanks for reading, Nicola!
@manuite I think can understand that, MongoHub does have a more "native" OS X feel and also has a few interesting features, but I still think it's missing a proper query console... You might try fotonauts' fork though, instead of the original one, since it's actively maintained...
Wow, I never thought about it :-)
@jonahoffline - Thanks for reading, Jonah!
I was using connect-mongo and Mongoose with MongoDB 2.4.5 in one of my projects, and I was a bit annoyed by the huge dependency-tree. Plus, they were using different versions of bson
native parser, so I thought this should tidy up the project a bit...
@jonahoffline - Thanks for reading, Jonah! I take it you're not a language purist and decided to try ICS? :-)
Interesting...
@wensonsmith Thanks for reading! Not just beautiful, but functional too :-)
Excellent observation, thanks for sharing! I thought there had to be something wrong with those frozen processes...
Nice, keep up the good work! Just a minor typo on the first code block (creating and accessing a cache) - should be cache
instead of cahce
:-)
Excellent writing, Jonah!
@jonahoffline - Thanks for reading, Jonah! Glad I could help you!
@lancevo - thanks for reading!
@searsaw Thanks for reading and sharing your thoughts. Usually I do install the XCode CLT, but things weren't working so straightforward in the first few days of using Mavericks :-).
Anyway, things are now on the right track and apparently this "hack" is no longer necessary. XCode and XCode CLT were updated to 5.0.1, the guys at homebrew worked frantically to catch up and the siege package was also updated to 3.0.5.
So, I'll update the tip with the latest info...
@zhuangya Totally agree. But on a development machine, people need to globally install things like nodemon, coffee, etc...
@seuros Nice, but a bit too complicated for a development machine, IMO.
Also, due to an issue in the homebrew package, I'd say the fastest & easiest way to get a Node.js development environment is still the official installer + sudo chown -R $USER /usr/local
.
@seuros Yes, you would. Which is still better than sudo
, I think. If you know of a better way, please share your thoughts :-)
I didn't know about -interlace
, thanks for sharing :-)
@fardjad - node-fibers is interesting, though it has its issues, but for people favouring CS / Ruby style syntax, I'd still say ICS is the best bet :-)
@brettof86 - that's what I knew. However, Max Krohn said on a number of occasions (including on this thread on stackoverflow) that he's planning to support ICS indefinitely...
So I'll definitely choose to rely on ICS for my future Node.js projects :-).
@brettof86 and @liuyanghejerry - totally agree about IcedCoffeeScript!
I've been using it for almost a year in my projects and I couldn't imagine writing Node.js apps without it. It just "blends naturally" with your app code and makes it look a lot more comprehensible...
I've also wrote a small "protip" on that, couple of months ago :-).
@brettof86 - You were saying Iced Coffeescript which is supposedly getting merged into coffeescript eventually. Would be great to see it happening, but... do you have a source for that?...
Nice!
@chrisullyott - I don't see why you couldn't
That's evil :-)
"Node itself is not even at 1.0, not that it lets anyone disregard it, but it needs mentioning."
There's also a catch here: Node.js doesn't follow the "accustomed" version numbering pattern. I know it's like comparing apples and oranges, but I'd dare say that, now, at v0.10.20, Node.js is a lot more mature than .NET Framework at it's 2.0, and more "in tune with the web" than .NET at 4.5 :-).
Well written!
Just a minor typo - I believe you want to say Node’s community is rapidly expanding, instead of expending :-).
Also, despite the debate on the upcoming ECMAScript 6, I think CoffeeScript is here to stay for many years. It will take a long while until browsers and the community will catch up with ES6 and CoffeeScript will continue to grow on top of it.
That being said, I'm one of those guys that say "it's better to learn CS after you have a solid understanding of JS" :-)...
Regarding the speed issues, I second your opinion. I've used .NET in the far past, then Ruby/RoR; I am now doing most of my coding in JS and CS and I can safely say there is a significant difference in responsiveness (which arguably leads to a lower TCO). I'm sure there are lots of more-or-less idealistic benchmarks trying to prove or disprove this, but I, for one, prefer to build an opinion on my own experience.
Thanks for sharing!
Excellent writing, Sagi!
It seems we share the same passion and views on the Node.js environment; I wrote a similar tip a few weeks ago - please have a look at it here: https://coderwall.com/p/diokxg
I also loved your take on simplicity - people having "a fetish for keeping web-apps as simple and as lightweight as possible" are, unfortunately, a rare breed nowadays :-).
Actually, I think its core simplicity is one of the reasons I've come to enjoy working with Node.js so much.
As the headline on nodejs.org says, "Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications." What it doesn't say is that, when you have such an excellent foundation for speed, an entire exploding community will start building useful features and functionality around that core.
In my opinion Node.js doesn't need a silver-bullet like Rails. Express and the other existing frameworks are powerful yet lean and flexible enough to leave room for innovation on individual projects. I'm an adept of simplicity too, and I'd rather start building my projects by adding the necessary features than by removing the unneeded ones before anything else :-).
Thanks for writing!
Nice, Ivor!...
Simple and straightforward!
Thanks for reading, Eduardo!
Never thought about it, but now it seems logical ;-)
Yep, CoffeeScript Ristretto is one of the best programming book I've ever read...
@Spaceghost's link above leads to IcedCoffeeScript, which I find to be the best way to avoid the "callback hell".
For non-purists / CoffeeScript haters - I wrote a long protip covering a real-world usage scenario here.
Thanks for sharing!
Nicely said!
In theory, the IT should be an industry laying on top of Maslow's hierarchy of needs, but I've met so many self-titled "professionals" still struggling on the "self-esteem" level that it makes me wander...
And there's also the issue of "everybody has to eat" - there are so many more-or-less-competent people climbing up the corporate ladders nowadays, and some of them have a constant urge to prove they deserve their place. Interviewing other people offers such an occasion.
I, for one, can't imagine how one can pretend to do HR/recruiting/interviewing in an area such as IT - especially coding interviews - without having a sound technical background... and without actually writing code.
"It's... ok for browser programming" - there's no other real alternative yet for browser-programming.
"can't understand why anyone would want to use it server-side" - that's precisely the main theme of the article. There are many reasons; a good foundation for speed and the ability to handle many concurrent users at a decent cost being one of them. I remember working on a RoR project where we had to do some image uploading and processing (on a regular, cheap PaaS hosting solution) and we were having issues on that part. We're having no such problems with Node.js.
"use what you want, it's your choice" - indeed :-).
Thank you for reading and for your feedback!
@borntorun - thank you for your kind words!
About starting to learn and use Node.js, for me it was a long - if not convoluted - yet rewarding path. Years ago I used to do a lot of coding in .NET (C#), then, due to a switch in my "career" and lifestyle I became more and more interested in open-source technologies. I went through Ruby / RoR for a while, then I found Node.js.
To build a good understanding of the language/platform, there are two excellent books I'd recommend every day, "The Node Beginner Book" by Manuel Kiessling and "Mixu's Node book" by Mikito Takada.
Also, if you're coming from the .NET world, you'll probably find that this is a completely different type of ecosystem and you'll need to get used to a completely different approach to learn things - for one, there's no MSDN you can rely on :-).
I'd also say a good understanding of functional and event-based programming is necessary, and I know many people have difficulties when switching from a purely OOP-based environment.
And there's the issue of ecosystem, as - in my opinion - the power of Node.js lays not only in the language flexibility and the V8 engine, but in the richness of its ecosystem as well; there's probably a module out there on Npm.js/GitHub for every use-case you can think of: authentication mechanisms, sockets, template engines, data storage, image manipulation, etc. So you'll have to get used to digging through them and choosing what's best for you :-).
If you're a .NET developer, you're probably using Windows; using Node.js in real life goes better with OS X or Linux.
And finally, build a REAL, complete "generic web project". As @crueber was saying above, there's a huge difference between "dipping in a toe" and "jumping in with both feet" :-).
Thanks for reading, Jonah!
Thanks for reading, @third!
Good to know, thanks for sharing!
@crueber - we've had the same experience, I believe.
Well said, about "jumping in with both feet" vs. "dipping in a toe" :-)
@munimkazia - yep, that one looks good indeed. Also, it's author, Jared Hanson wrote passport.js, - the "de-facto standard" in Node.js web apps auhentication.
@christian-fei - thank you for your kind words!
@mattnull - Mine too, I think! Though I'd say it's more of a platform, not a language...
@zilti: "JavaScript, which is a half-assed programming language" - the Internet is (still :-) a democratic environment and each one is entitled to an opinion. I've used C#, Java, PHP and JavaScript. They're just tools, not religions, and all of them have strengths and weaknesses :-)...
@marcoslhc: Thanks for reading!
In relation to hosting providers, in my opinion AppFog is a good choice, while Heroku is an EXCELLENT one; I haven't tried Joyent yet, but I've heard only good things about them. And there are many others...
Yep. It happens in many prestigious companies. Also, most tech guys have egos bigger than themselves, but very few of us reach to the philosophy of "doing the best you can with what you have".
Nice post!
Thanks for reading, @tiberule!
Yes, IcedCoffeeScript does help a lot; actually I believe it is one of the main triggers enabling people to approach "generic" web projects in Node.js. I know there aren't many examples of you could/should use it in real-word apps and I was also considering the idea of publishing some kind of "how to" (and I'll do my best, but unfortunately I don't think I can do it sooner than 2-3 weeks :-).
Until then, I'll try to answer some of your questions here.
No, I haven't used Brunch (but it does look interesting).
LeasingSH.ro has a rather simple Express.js-based MVC architecture; I'm using Mongoose models and a custom controller definition & loading implementation, because the routing mechanism had to be very flexible. For client-side asset management & packaging I wrote and used ASPA (you can check it up on npmjs.org), but there are many alternatives out there.
Also, to get most of our PaaS instance I used Node.js cluster processes - they're still marked as an experimental feature, but in my experience they've been working perfectly, and are making a difference in speed. I plan to write a quick tip about that as well soon :-).
Sorry about the apparently misaligned code in the above sample, but I was using a 120 chars per row standard in that project :P.
@battlemidget - thanks for reading!
"[...] still javascript and that is tolerable at best" - I thought the same initially, but in the end it's a matter of personal preference and - as I was saying in my too-long pro tip - the subject will always spur "religious" debates :-).
The far-future? I really have no idea... I mean, who'd have thought about Node.js five years ago? As you were saying, like CS, TypeScript is another layer on top of JS (although it does bring some interesting features). Dart definitely looks interesting. But in the end, I thinks it's a matter of building an rich and open ecosystem around it. I think we won't really know until it's there.
Thanks for reading, @sb8244 !
About a CMS comparable to Joomla or Wordpress - yes, I think you're right, and I was seriously considering the idea of starting such an initiative, then I discovered this successfully-funded Kickstarter project:
http://www.kickstarter.com/projects/johnonolan/ghost-just-a-blogging-platform
They say they're planning to have the first public release in September this year, and I'm kind of anxious what they'll come up with. If they'll keep up to the campaign, I think they have a good chance to change the landscape!...
Thanks for reading, @samwu123 !
@knivets - Thanks for reading!
The Sublime Text theme is "Dark Soda", with "Tomorrow Night" colour scheme.
I'm also using a custom fork of "BetterCoffeeScript" plugin to highlight "await" and "defer" ICS keywords and to see the ICS -> JS compilation result whenever needed.
@sheerun - agreed. But for those preferring CoffeeScript, ICS is also a good alternative :-)
@chris089 - thanks for reading and you're right, of course, sorry about that. I'll try to keep them shorter from now on.
Initially, it was supposed to be shorter, however, you can regard it as a "collection of related tips" :-).
However, there's an UX problem here - there's no message / error feedback about the content length when you're trying to publish...
Nice tip, John!
I'm using OS X for almost 3 years and had no idea about SIPS. I've recently had to generate/process about 60,000 images for a project, did it with with ImageMagick - which is great, but you do have to brew-install it :-)...
Hi Dung Quang,
Thanks for reading. Yep, after 15 years of stillness, the JS world is evolving fast and IT IS chaotic. But so is most of the world nowadays, isn't it? :-)
Totally agree about CoffeeScript bringing beauty and and concision. By the way, there's a great short book on CS, you probably know about it already, but other people might not, so I'll post the link here: http://arcturo.github.io/library/coffeescript/
Dart looks promising and - referring strictly to the language, it has everything JS is missing. But he whole Internet has to catch up with it, so in my opinion we're won't see wide-spread adoption for 5 years to say the least...
Hi David,
Thanks for taking the time to read. I know about the irrational hate... But people can be irrational about many things :-).
If you're not against CoffeeScript, you should definitely try ICS!
Sorry for having to break it up into 5 parts, but apparently there's a limit on the text size somewhere...
Sorry for having to break it up into 5 parts, but apparently there's a limit on the text size somewhere...
Sorry for having to break it up into 5 parts, but apparently there's a limit on the text size somewhere...
Sorry for having to break it up into 5 parts, but apparently there's a limit on the text size somewhere...
Sorry for having to break it up into 5 parts, but apparently there's a limit on the text size somewhere...
Nice one. After using IcedCoffeeScript for a few months, now I can't even imagine writing Node.js apps without it. I'd like to see more developers using it, as it elegantly mitigates one of the major drawbacks of Node.js.
I've recently published a similar pro tip showing a "real world" usage scenario.
Most developers SHOULD care about this.
I think everybody involved in web development / programming should read the books and articles of Jakob Nielsen and Don Norman...
I'm not exactly a social network geek, but my first impulse was to share your post. Which proves exactly how right you are...
:-)
For people working with Node.js / CoffeeScript, I'd also recommend "Better CoffeeScript".
So much shameless advertising about that "long path tool" or whatever it's called...