What is really interesting to me is how are they doing persistence.
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.
Didn't say they're far from each other, of course it may be possible. I'm also aware of Microsoft's support for Node and Azure, and their contributions to Node.
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.
Thanks. Without getting into FUD - I have my own MongoDB battle scars as it is on Linux. I can't imagine running it on Windows, sounds like I'd be very lonely should any problem arise there.
There is plenty of hate here and on Reddit for Node. My experience was fairly painless. My unit tests ran incredibly fast... that was such a relief coming from JRuby/Ruby. Otherwise, the language does feel a bit constraining. If you've done plenty of work in JS though, it's not bad to get into. I really loved Express.js for the project I did.
Ok, everytime I read about Node it's usually made clear that is perfect for websocket type of apps that can network and have multiple users interacting between each other. So, in this case Myspace, seems to me like a regular app/site that does normal operations. So, Hopefully someone can explain to me if Node is also being considered as a replacement to the popular backend languages to build regular sites?.
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.
Well that is not really a problem with Node itself. Are there any framework like Rails for Node? Then makes ( or try to make ) all the best options for you?
Tower exists, but the issue is that unlike express, which runs Learnboost, there aren't any Node users who both a) want to build their for-profit application on Node while b) being willing to write their own framework.
I mean, I don't really know what you call "normal". Is normal serving up a static blog? Is normal serving up non-realtime content? Is normal small scale?
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 :)
Node (with or without Express) works great for normal websites. People used to always argue it was only really good for realtime collaboration or networking stuff, but with the amount of frameworks etc. in npm and elsewhere that is not true anymore.
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.
It can be. Have you tried Trello, Geekli.st, Klout, Prismatic or Clipboard? They're all Node too. It's had frameworks for developing web applications for some years now.
Nobody said anything about successes. The question was whether anyone was building regular websites (as opposed to just websocket/API stuff) with node.
Thats great , its been several days since I posted this question and based on these great answers I decided to start learning it, so far so good. I got the book "node.js applications with mongo.db and backbone.js" , since I have messed with mongo and php before, seemed like a good idea.
For some reason, Node was initially associated with real-time apps. This isn't really valid.
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.
> The level of language proficiency required to make an app with Node/Express is probably higher than with Django or Rails.
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.
The Myspace you're referencing to is not the current Myspace. The company was bought for $35 million in 2011 by Specific Media and Justin Timberlake. Same brand, different product.
A lot (and I code in it day-to-day) but part of me actually wonders why. Node is great for websocket-type, async operations. As a normal web server, serving pages? I feel as though other platforms might work better.
A lot ! i bet as much as startup using python or ruby as their backend. NodeJS is not for everything so it would be interesting to know how they use it. I'll be curious about what their persistance layer is too.
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 ...
There are tons and tons of use cases for sharing code between server and client. Why would you want to write things twice? The only reason it is not more common is that programming is generally done in different languages on the server and client.
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.
I just built and launched https://popbasic.com/. It shares the router, controllers, actions and templates between the client and server. I have the "frontend" that runs client and server which then talks to an api.
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.
Cheers. I don't consider myself a designer. This is the first creative thing i've done in 10 years, so it's good to know i can still make something that looks good :).
Very, very rarely. Along with "now you can get your frontend developers to write backend code!", it's one of those oft-cited but spectacularly bad reasons to start using JavaScript for non-client stuff.
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.
Not sure though. But top of it you would probably use backbone.js in both server and client. Another advantage is we have UI developers who are now writing server code to be much more. To some level it is giving a path way for one language everywhere paradigm. However, server side coding required much more capabilities like performant code, scaling etc., but for normal websites it is easy to go with node as it kills some amount learning curve.
Even if never, the idea is to reuse skills, not code. (In the same way that you reuse little code from Rails apps when build Chef recipes)
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.
My situation was different to this, but when sharing C# between a backend server and an iPhone app I found it tremendously useful to use the same models, and just JSON encode/decode them to transmit between the two.
- 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