New MySpace done with Node + Express
expressjs.com
expressjs.com
- extremely well designed form fields when signing up (kind of plain, reduced and flat but more colourful than Metro)
- in general very clean, subtle UI/design
- low latency, responsive servers, feels snappy
Well done (from a webdev perspective, don't know if MySpace has still a valid use case but I read that it should be more like Spotify now)
EDIT: after playing around a bit I have to stress again how responsive the site feels => ultra low server response times
EDIT2: when watching a video and surfing around, the video stays as a small inscreen window on the screen
Node and SQLServer? Sounds very harsh. MongoDB? does that run on Azure?
My bet - their Node servers proxy to the old servers via dedicated API for data. Node should be fine at doing these requests due to its async nature.
Even when you run with Express, to build such a feat requires a TON of infrastructure (did you notice the X-Tracking, X-Response, etc headers?).
Much of the open source/public infrastructure in the Node ecosystem feels raw (example: loggers. did you see how many loggers there are? do you think they're production worthy?).
Though I would accept this and fix whatever I can (took me a while to find a proper hierarchical logger that is also async, for example), I find it hard to grasp how Microsoft would. This makes me assume they built everything from scratch.
Look at WebMatrix, their simplified web development tool, I was surprised to see that it supports Node: http://www.microsoft.com/Web/webmatrix/node.aspx
Same goes for Azure: http://www.windowsazure.com/en-us/develop/nodejs/
Last time I wanted to integrate postgres with Node, I had flashbacks of myself, 10 years ago, building an ORM before ORMs were that hip - this is true for any of the impedance mismatch offered by taking an RDBMS and plugging it with Node. I think there's something with using stores such as MongoDB with Node that feels very right, almost essential.
I don't know about you, but I don't really don't know what "normal" is anymore. Express (and many other newer web frameworks) have really shaken up the landscape. It's not Apache vs. Dynamic webapps, it's much more than that.
Express is less of a different web framework suited for realtime and more of a different way of thinking about what a web framework is. The paradigm and platform it's built upon happen to make realtime a natural feature, but by no means is that the only thing express is useful for.
Express (and indeed, most any other sufficiently mature and flexible framework) is as versatile as you make it. Please don't pigeonhole Node :)
I like doing Node.js and front end using things like CoffeeScript (and maybe Jade etc.). Also there is LiveScript which is an awesome option that I would like to get into.
Node is great if you have a JS heavy team, and want to have one language to rule them all... and potentially share logic using something like Browserify.
In our experience on Vidpresso, we started out with a Node app... however for the core app we found that Rails' productivity gains outweighed Node's sharing of logic, etc. With a bootstrapped team, Rails' maturity just made Node seem like not a good idea. (Django would be fine too, but one of our core guys has done rails forevs.) We still use Node as a critical part of infrastructure, but now it's relegated to message bus / socket.io-ey stuff. (Talks with rails via redis pubsub.)
So yes, you can totally do your entire stack on Node... but you have to make a lot of decisions. If you're someone like TJ (the guy behind express) and you're comfortable making lots of decisions yourself, it's extremely great.
FWIW for Node noobs, Express is just like Sinatra. There are higher level frameworks, but none that has really 'run the table' like Rails or Django.
I'm sure it's coming, but just not here yet.
But you _really_ need to know Javascript. The level of language proficiency required to make an app with Node/Express is probably higher than with Django or Rails. I found it very productive once the initial hurdles were crossed.
Let me add my thoughts: Yes, you need to be good at JS and Node.js but to get there is easy. Maybe these thoughts about JS and that you have to be really good at it come because most of the people who know JS are rather people who fiddle from time to time with JS in the frontend using jQuery doing some DOM stuff (like me before). So, yes you need to know more than that.
But: to get there is from my point view much easier than getting good with i.e. Ruby and Rails. Just because you can build a blog in 15 minutes doesn't mean you can program with Rails after 15 minutes. Ruby is heavy (and not consequently more innovative than JS), Rails is ultra heavy with all the conventions you have to learn. In contrast, JS is a sophisticated, modern language and understanding its core concepts can take a while but in total it's more compact regarding the knowledge you have to learn. After getting into JS you need maybe one or two days to get into Node and Express. And little things like the npm surpass the rvm/rbenv/Bundler struggle by far (npm just works, period). Alone the npm is worth trying Node: its elegant design paired with Node's modularity are unmatched.
I was much earlier productive than with Rails since Node/Express forces you to think yourself about structure and this makes your more powerful, more smarter -- and just faster. Instead of learning convention after convention you just think about how to code which is much more fun as well. Besides, JS' built in data structures (in particular JSON) and design patterns are amazing and showed me that classic OO maybe isn't aged but very often overcomplicating simple things (the web is not all about CRUD and even then Node is a great answer).
Since I don't know Python/Django very well I can't draw a comparison here.
http://online.wsj.com/article/SB1000142405270230458400457641...
I like the new interface , it's cleaner that it has ever been , BUT if i get pushed too much spammy stuffs i'll quit. Right now i dont see why i should use that, all my connections are gone ...
If you are wanting to stick with "one" language for both server and client-side, then Node is a good choice.
Data types - Both concrete classes or helpers for manipulating data.
Input Validation - Do it client-side to do it fast, but double check on the server.
Formatting - Larger web apps often need to format things from dates to users to numbers on client-side generated data without the server hop.
Templates - Many templating systems are compatible with multiple languages, but its easier if there's just one output type.
In saying this, I use node for a heck of a lot at work, but that's mostly because some of the workflows available (streams and events specifically) are perfectly suited to the programs I write in it; not because it lets jQuery monkeys crank out substandard backend code.
It works pretty good because i can serve out a full page request (good for SEO and fast load times) then boot the same application on the client so subsequent navigation is fast.
That's not entirely true - you can reuse some libraries between client and server-side: underscore's utility functions are the underpinning for many node modules, sizzle and jQuery is great for DOM parsing when writing screen scrapers, etc. There's browserify if you want to run node modules in the browser.
I built an ebook reader that can process ebooks in javascript. Because IE does not support the File API the server needs to pick up the slack when users are on that browser. Sharing code means I don't need to program two versions and I only have to patch bugs once.
It's also common to share validation code. This allows you to check data client-side and then again once it reaches the server using the same code.