Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have been trying to create a mongodb server which will receive post requests and insert or read from a mongodb server and reply back. I have started with node.js. However while I was reading stuff, I have been realizing, people actually hate node.js. Many people are crossing to GO. So I am all confused now.
I have chosen node.js because of the natural json compatibility of javascript. However after all the things I have read, node.js sounds like a waste of time.
Could someone help me clarify my confusion ?
Thank you.
Edit : People refer to the problem of callback hell, and lowering performance of node.js once the business logic starts to be more complex than simple loops.
People refer to the problem of callback hell
This has never been an issue for me. You can use whatever structure you want in your code. Any promise library may be helpful if you find that you really need 1,000 nested callbacks, but this is rare in most circumstances.
lowering performance of node.js once the business logic starts to be more complex than simple loops
Rarely is this a problem. Most applications are IO-bound. If yours isn't, you have a couple options. One is not to use Node.js. Another is to compile a native extension for the specific part that's dragging you down (since you'll be writing native code to solve this problem anyway) and call it from the rest of your Node.js application. That way you get most of the performance of your native code but still get the flexibility of working in JavaScript.
Since you linked to that Reddit post, I'll address some of the comments there.
Javascript is very fast. Yes this is true, V8 is very fast... however, only if you are benchmarking a simple benchmark. As soon as you start adding in complex application logic all that performance goes out the door because the virtual machine has a very difficult time correctly inferring the type and thus not being able to optimize. But if your application consists of a tight loop, it will be fast.. so its got that going for it :D
It's all relative. No doubt that weakly typed and interpreted anything is slower. It's a trade-off that you have to decide makes sense for what you're doing. Personally, it's far cheaper for me to fire up another box to handle the load than it is to rewrite all of the helpful modules and frameworks I use in Go. Maybe that's not the case for you, so you get to decide.
In my 3 years of full time node.js development, I have honestly only had ONE occasion where I used the same 4 lines of code both in the server and in the client.
This is generally true. I don't understand why shared client/server code is some sort of selling point for Node.js, as it isn't for most applications. I had one case where several classes I wrote for an RPC layer ran on both the server and the client. One thing I will say though is that there are a ton of NPM packages that run in both so if you get used to using a nice package on one, it will often times work on the other.
Ohh and did I mention Node.js isn't really all JavaScript? A good portion of the pakcages on NPM are also written in Coffeescript. Hope you don't mind learning another language to deal with a package you depend on. So much for using the same language for both server and client!
You don't have to learn Coffeescript to use an NPM package written in Coffeescript. Coffeescript compiles to JavaScript, and are used in your code the same way any other package is. Also, those same Coffeescript packages do run just fine in the browser since it all builds to JavaScript.
With Go you get type safety. This CANNOT be overstated.. except to maybe ruby-ists(jk jk! don't shoot me).
It's up to you to decide if this matters for your use case.
The one benefit you have with Node.js over Go is the massive number of packages available on NPM. But most of them are useless abandoned junk. So, even that is questionable.
Don't use abandoned junk, just like you wouldn't with any packages on any platform. It's very easy to see what's abandoned junk. NPM calls out what's been updated and when, whether or not its dependencies are up to date, and how many people are using that package. There are definitely a massive number of useful packages available for Node.js, just like they are for most popular platforms.
Testing: Lets just say that in Node.js/Javascript you would have to write tests that check the type of a variable. tsk tsk tsk... This is the only way to properly test JS and make sure nothing crazy is going on.
That's not really accurate, and I'm really curious what's going on in this person's application where this is necessary.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am programming since quite some years now.
Until now I was mainly focused on writing "normal" applications which run inside a console or with a GUI, sometimes also applications which interact with hardware components such as sensors / actors / ...
During this time I got to know a lot of cool programming principles and tools such as object orientation, modularization, unit-testing, test-driven-development, desing-patterns, code-analysis, ..
Also I have some first experience with hosting a wordpress blog, running static web-sites on a nginx webserver, and writing some small php-forms. But I feel like there is still too much magic in all these web-development topics. And I would like to fill this gap and learn a bit more about all these connected scripting / programming languages and technologies. (Because I hate, when I don't understand how things are working :D :D )
I started with some online "Web-development bootcamp" course at udemy to get a rough overview. This took quite some days now and I think HTML, CSS and Javascript for DOM manipulation / animations are clear to me now. Also I heard a lot about NodeJS and all it's derivate languages and databases like Mongo-DB. But still I feel like there is a lot of things unclear to me.
To get to a better understanding I wanted to development some small web-application. Nothing very special, just some website where you have to login to, are able to generate some data and this data is then persisted into a database and once you login again you are able to see the data again.
I first started with developing some classes in Javascript to represent the data in the browser while you are logged in. But I very soon realized that the Javascript which can run inside the browser is very limited and already for unit-testing and modularization into separate files that include each other I actually needed to do some crazy work-arounds or use other server-side languages like nodejs / php / ... .
After some time coding I decided to take one step back, trying to understand the basic design patterns of web-applications and not running for a long time into the wrong direction.
My questions are:
Is there some typical way to go / best practice while developing web-applications?
What are the typical key players? I know there is the difference between front-end, back-end and databases.
But are there some do's and don't's that good WebDev's follow?
For example:
which code is usually written in back-end / server-side languages?
What is usually done in the front-end? (Only desing and animations?)
Do I have to move all business logic into the back-end, also for security reasons or is this maybe also a bad idea because of peformance reasons?
What programming languages are more or less dead and not to be used in the future?
What things are typically reused from frameworks, for example authentication and session handling?
Also I felt like some things I know from other programming languages are not so easy in languages like javascript / nodejs. I am willing to spend time and effort into learning all these things but I would also like to keep the quality standards that I know from C++ /
Python. On the other side I also wondered if these patterns that I have in my head are maybe just boundaries that are completely useless in modern web-development? (e.g. typing, object orientation, modularization / splitting the code to be very reusable )
What do you think am I on the wrong track here, or do I maybe simply use the wrong languages?
I hope the long text is not knocking everyone down / keeping everyone from answering me :o
I would really appreciate your help and guidance to understand everything a bit better and to not repeat the things already a lot of others have done wrong ;)
BR, mezorian
First off, most of the questions are very opionated (at least the answers are) and your question will probably be closed for that reason. So I will post my answer before completing it and expand on it after.
First off a good roadmap to become a web developer. I like it mainly because it shows the crazyness the web development world has come to (don't be shocked!): https://levelup.gitconnected.com/the-2020-web-developer-roadmap-76503ddfb327
Trying to answer some of your question (answers are my opinion):
Is there some typical way to go / best practice while developing web-applications?
I'm tempted to say there are as many ways to do web development as there are web-developers in the world, but that might be a bit exaggerated. If you want some guidelines, I'd pick one of the major web frameworks and learn the way they do web development. With web frameworks I mean all kinds of frameworks starting with JS-frameworks all the way to static site generators, etc. They all have their ecosystem and their own rules.
What are the typical key players? I know there is the difference between front-end, back-end and databases.
(personal opinion) I work with Go in the backend. I love it because it brings back some simplicity in the crazy world of choices being a web developer. Since you know C, Go will probably be easy for you. It has static typing, structs, etc, but no need to manually manage your memory. It is also much faster than most other backend languages used in web development (Python, NodeJS, PHP, Ruby, etc).
In the front-end I have used native JS, jQuery, React, Vue, etc. I'm still waiting for something that makes things easy again. Flutter seems to be something that has a good approach, but is not really a web front framework (yet). (Don't do public websites with Flutter! They are not indexable.) We'll see where it goes.
Databases I will not go into here as that is another huge topic. Let's just say that I'm more a fan of using multiple databases for their specific strengths rather than a big one that is supposed to be good at anything.
which code is usually written in back-end / server-side languages?
Even this depends largely on your choices (framework and preference). One thing for sure has to be in the backend and that is security related stuff. Anything you put in frontend code is visible to an experienced user.
Apart from that there are some ecosystems where you don't write any backend code but talk to a (cloud) service that is basically like a database with a web endpoint on top with secured login. (for example https://firebase.google.com/.) Here the security related stuff is baked into the service.
If you do both, keeping business logic in the backend is probably a good idea. If the frontend calculates something (for quick response), the backend should double check that (e.g. calculating the total in a cart). But this is too general. There can always be use cases where some business logic needs to be implemented in the front-end.
Do I have to move all business logic into the back-end, also for security reasons or is this maybe also a bad idea because of performance reasons?
Performance can be a problem, but mostly because the roundtrip time to the server and back. If you do that for every tiny information, the UI will become sluggish. You might want to think about doing e.g. a calculation client-side.
JS-Frameworks like React, Vue don't request html from the backend, but data and build the html based on that data client-side. I'd use them if I have a very data driven website / webapp, especially if it is user-dependent. Transferring only the data and building the html for every site from it in the browser based on user settings and data, saves a lot of roundtrips.
If you are worried about server performance: For the server to hit its limit, you'd need heavy usage of your website for that to become an issue (at least with Go). If you get there you can still use horizontal scaling (multiple instances of you server) to solve that. Unless you are working for a large company with millions of users daily, I'd not worry about scaling for now.
What programming languages are more or less dead and not to be used in the future?
Warning: Very opionated!
I'd say PHP is dead. Many headhunters I've spoken with agree with me. Companies are desperately looking for PHP developers, because many developers are moving on from PHP to something "cooler". You'll definitely find a job with PHP, but might not be so happy with your job. For me it is also a sign of how modern a company really is (if PHP is not it's main backend language (any more)).
Python currently has a big boom. Mostly because of AI development. I'm not sure if that boom is also in the web development, but I'd say not. I used Python before Go (5+ years ago) and before that PHP (8+ years ago). I rarely get Python web developer job offers (at least compared to PHP and Go).
Go is the language of the cloud. It is perfect for concurrent programming which is an essential part in web development (every http call should be handled concurrently). It is fast and light weight and doesn't need anything installed on the server to run (compiles to a single binary without dependencies).
NodeJS: Haven't used. I'm not a fan of Javascript (but it was (and kind of still is) the only option in the browser), so I never liked the idea of using it also in the backend.
TypeScript: might be an alternative to JavaScript (thinking of frontend here) if you like a more structured language.
It sounded like you want to build a user baser web app with data being managed by each user. This is what I would (probably) do in that case:
Backend in Go
Go serves static files (start html, css, js, images, etc.)
Go server has an api endpoint that serves data (e.g. REST style)
Vue (or React) in the frontend
Vue requests data from the api to build the user-specific content
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am really confused with everybody in JS community using Node.js and NPM with their JS libraries. Why do we have to resort to such extreme measures? What problems is this solving for us?
[Edit]
I think my question wasn't to the point.
Frameworks like Ember.js, Batman.js and more recently Yahoo's Mojito require me to use node.js - why this dependency on Node.js and NPM?
Why are we making things complex? "If you haven't already, you'll need to install node.js..." You read messages like this and you're turned off.
Why? There is already a problem of plenty in JS - far too many active JS libs/frameworks to choose from - going by the record of JS libs most will become inactive soon. There are just too many things to look for that often result in multiple frameworks in an app - dependency management, routers, MVC, templating, etc. On top of this we are using Node.js to use these libs/frameworks... How will this push usage of these libraries to new JS developers? JS was meant to easy!
"If you haven't already, you'll need to install node.js..." You read messages like this and you're turned off. Why?
NodeJS is Google's V8 "running on it's own". It's a JS engine with additional low-level API (Network,I/O,etc.). NodeJS provides "the missing platform" for JS developers, who were just limited to working on a browser.
why this dependency on Node.js and NPM?
Node.js, aside from using it as an app (servers, proxies, bots etc.), it can also be used as a tool build and aid development. Take for example Grunt which is a scriptable automation tool which is similar to Make. Scripting in just plain JS, you need not learn another tool or language to do automation. Another tool is Bower, which is a front-end package management tool. All you need to do is a bower install jquery and it installs jquery with that single command. No need for manual download, copy and paste.
NPM, on the other hand, is Node.js' package manager. It's a program that manages the modules you use on NodeJS. No need to list down your modules manually, and no need to remember them when you develop somewhere else. As long as you have the package list NPM made for you, reinstalling is just a matter of npm install.
Why are we making things complex?
We're not. In fact, we're making them easy for developers. Instead of worrying on your workflow, managing your libraries, or doing stuff manually, you can off-load these tasks to some of the modules that exist on NPM. Then you can just focus on what you are actually doing.
On top of this we are using Node.js to use these libs/frameworks... How will this push usage of these libraries to new JS developers? JS was meant to easy!
Like mentioned above, NodeJS is a versatile platform. It can be used as a server (Connect, Express), an automation tool (Grunt), a package management system (using NPM, Bower etc.), a testing platform (QUnit, Mocha), a proxy, game server, chat bot.
And it's beneficial, especially to the JS developer, since these weren't possible in JS.
There is already a problem of plenty in JS - far too many active JS libs/frameworks to choose from - going by the record of JS libs most will become inactive soon. There are just too many things to look for that often result in multiple frameworks in an app - dependency management, routers, MVC, templating, etc.
Well, it's good to have an abundant set of frameworks. Your work will be cut in half after learning some of them. Implementation diversity is also good, to address different styles of coding and different approaches of implementation. Some libraries rise from differing approaches, while others rise from the incompatibilities and/or incompleteness of others.
The developers are hard at work to make life easier for other developers by normalizing JS quirks (because browser vendors just can't seem to do the right thing of following standards) and most of them are done voluntarily, like free beer - you should be happy for that. Besides, nobody's forcing you to use one anyway.
The CommonJS standard (best implemented, in my opinion, by Node.js and NPM) introduces the concept of modules to Javascript. For years, the Perl and Python communities have demonstrated why modules are awesome:
Unix-style "do one thing and do it well" libraries that are small and heavily tested against bugs, that can be combined easily (with no namespace issues) to solve your particular task.
Central repository of open source modules (CPAN, NPM, etc) that you can easily pull the modules from (NPM takes it one level higher by keeping all of the versions available, so you can specify that your code uses the last known "good" version rather than hope that nothing broke when you redeploy a la CPAN).
Greater peer review of the code (since they are more easily composable, they're used in more varied situations, so this is what helps reduce the bugs, but also what helps improve the modules to be more generalized).
Greater variety of tasks solved. Since the libraries are short, pretty much anyone can write one. That does mean there's a lot more crap to filter through (articles about widely-used libraries help with this), but it also means a library that solves some very specific problem (such as localizing strings and dates ) probably also exists.
And then a Node module called browserify makes the actual build process for your client-side code incredibly simple, and you can use just about any piece of code you find on NPM.
This breaks away from the "kitchen sink" mentality of libraries like jQuery (who have developed their own custom build system so they can start modularizing their code, too) that believe they need to solve every problem their user might have, rather than just produce results that can be used by other libraries.
Very often you needs different builds of your javascript. Usually it is spread out in different files, sometimes its in coffeescript.
You often want a build AMD compatible build, as well as CommonJS one, plus regular minimized and unminimized builds.
There's also the potential for dependency resolution.
I've even seen a library that had a build for jQuery and protoype...
Edit: noticed I was answering the question as worded in the question body, but missed the compilation question in the title.
What criteria do you have for considering this an "extreme measure"? This has been done for years, for the sake of writing clean, easy to read/write code, but precompiled to be optimized for on-the-wire transfer (and perhaps other optimizations as well). Node.js makes a nice solution for this, simply because it's also using JavaScript and therefore familiar to people using it to compile their JavaScript code. Previously this was typically done in something like Python, which, though working, seems less sensical to me than sticking with a common language.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have been really playing with node.js alot here lately. I really like it and would like to get serious about building a site that I have in mind with it. There are just a few things that I had questions on. I am currently using express, cluster, mongoose(mongodb), and dust because it seems like the community is doing pretty well with this setup.
The first question that I have run into is making changes in the app. If I change one of the files in my app (with the exception of templates), I have to restart the app in order for the changes to show up. Is there something out there that will do this automatically or is there something I am missing?
The second question I have is, are there any really good resources out there that anyone can recommend. Seems like alot of the stuff that I have found through google just explains one topic and there are not alot of books on it yet(see some good ones releasing this year though). I was wondering if there was a really good resource for node applications (really interested in how people are structuring there applications and what they are using).
The third question or really feedback I would like to get is what good node modules should I be looking into using for my application. I really like cluster and running apache benchmarks with it versus without it I saw a double in the number of requests it could handle when using all 4 cores versus just the single core. I want to try and keep my code so that I dont have to write the logic twice for the backend / frontend which is why i have decided to use dust as my templating choice.
The last thing that I would like to know is based on an article that I read by linkedin (http://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates). After reading this article I was just impressed by the ingenuity that they came up with to do this. I see many benefits from this by saving bandwidth on the server from not having to server process the files each time and letting the users browser do the load. It also will allow for less bandwidth throughput by not sending the whole template to the browser every time and caching it. But I am just stumped as to how they accomplished this. Can someone please shine some light on this subject or if you know of a good article that explains how to do this it would be great. I dont know for sure I would use this implementation but I would love to know how to do in case it is applicable.
Thanks for any feedback.
First question:
Actualy there are multiple tools that do the job starting from nodemon to supervisor
Second question:
Learning materials
videos: nodetuts
books: from node beginner and more books
podcast: nodeup
alot of great bloggers: laurenzo | Peteris Krumins about usefull nodejs modules | dailyjs and many more
grouped modules: toolbox.no.de (for unknown reason not working now)
Not to forget nodejs docs. Also browsing github and reading source for great nodejs modules or apps can be quite good for learning.
Third question:
i think my Second question answer includes this one also.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I work on studying the development of a medium web application intended for hotlines. So I've real time, concurent access, big datamodel and CTI constraints.
Originaly I'm a php and Java EE developper, but like many of us, I've read a lot of news about node.js and I tested it with small apps. The possibilities of node.js are awesome, but I felt that it's very difficult to only use this technology in a medium/big web app. Indeed frameworks like express are minimalistic compared to productive framework like symfony, play or ROR, etc. Moreover, the node.js ecosystem progresses very fast and might be difficult to maintain.
I'm not experienced enough in nodejs, so I want to know; is choosing only node.js to develop a medium/big business web app with some real time problematics crazy or not? Don't you think that coupling a productive framework with nodejs only for specific features (real time) is a better way ?
Thanks,
Regards
Eric
I'm working on a large real-time business web app that requires some real-time interaction and what we are doing is using django for just about everything, and handling the real-time stuff using the now.js library. Originally we planned on using node.js for everything, but to alleviate some time constraints, we decided it would be quicker to use django.
One thing we have noticed since we've started is that there are a lot of changes, and that some of these changes break what we've done. For the most part, keeping up with the changes hasn't really made it difficult to maintain, however it has made it difficult to follow tutorials and such.
I'm going to answer this quickly, before the question is closed for only being answerable via opinions, not facts.
So, I'm going to answer with my opinion ;)
I think node.js's focus currently is on building small things that respond very quickly. I sense a lot of pushback in the node community against "too complicated abstractions". (It's possible I'm misreading the community, but I don't think so).
To me, building a business app (example: some of my past Rails projects have been 10ish man years) I want an ORM abstraction layer, etc. I think you'd want this building even an app with more than a few man-months of effort in it.
Unless something changes (the node community runs into problems when their code bases grow too large, for example) I suspect the "place" for node.js in medium to big applications is for small hyper responsive things (websockets, retrieving data from external sources and doing small things with it), etc.... not for building an entire big business workflow app.
It's 2016. Recently I decided to go with Sails / Node instead of CakePHP. Today I decided to go back to CakePHP. Lucky enough, I just coded one small module ( kinda of indexing inside a db some filesystem content ). The amount of callbacks and promises It's just annoying to me. The simple task of getting a file's metadata, searching it on Postgres, creating the record only if it doesn't exists, take me more than 20 lines of code and I almost have to drink a bottle of Dramamine lol
This time I am highly determinated to maintain an extreme layer's separation. So my front-end is fully static html/js/css, coded in Angular. Postgres DB also don't require any changes. And CakePHP 3 is almost factory's ready to easily serve json/xml.
Also there's a possibility of me being somehow stupid... lol
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
So I finished watching Douglas Crockford's excellent series on Javascript, and in the final episode (so far), loopage he lays out why Node.js is a near perfect solution for server side code.
He talks about keeping state, not in the database, but in closures running in Node.js, he also states that templating systems (like JSP, PHP, and ASP) are a poor abstraction for more complicated Web Applications and that node.js provides a solution to this.
And I am ready to buy in, but I can't find any examples of Web Applications using this pattern, or any books or tutorials about how to go about doing this. I am not talking about a simple application, but something that would use the patterns that Crockford spoke of in his talk. Anyone know where I can find some tutorials/examples of Web Applications written in Node.js (and yes I know about Geddy and ExpressJs, but they don't seem to follow the radically different patterns that Crockford was speaking of, and were more like getting a Railsy experience on Node.js).
[Note from 3 years in the future: It seems like Express, Geddy, Sails, Kraken et all are re-implementations of the Rails/Symfony/Spring frameworks from Ruby/PHP/Java. Whereas things like Hoodie and Meteor are attempts at a whole new paradigm. KOA looks interesting, but is a ways away from being usable, but looks like it is building on the strengths of javascript with the history of MVC applications of the past. 3 years on and it is still exciting times for Nodejs, even if it is no longer the new hotness. At least there are a lot of real world examples of Node in use now...
I would suggest you check out the various tutorials that are coming out lately. My current fav is:
http://nodetuts.com/
Hope this helps.
The Node Knockout competition wrapped up recently, and many of the submissions are available on github. The competition site doesn't appear to be working right now, but I'm sure you could Google up a few entries to check out.
DailyJS has a good tutorial (long series of 24 posts) that walks you through all the aspects of building a notepad app (including all the possible extras).
Heres an overview of the tutorial: http://dailyjs.com/2010/11/01/node-tutorial/
And heres a link to all the posts: http://dailyjs.com/tags.html#nodepad
Update
Dav Glass from Yahoo has given a talk at YuiConf2010 in November which is now available in Video from.
He shows to great extend how one can use YUI3 to render out widgets on the server side an make them work with GET requests when JS is disabled, or just make them work normally when it's active.
He also shows examples of how to use server side DOM to apply style sheets before rendering and other cool stuff.
The demos can be found on his GitHub Account.
The part that's missing IMO to make this really awesome, is some kind of underlying storage of the widget state. So that one can visit the page without JavaScript and everything works as expected, then they turn JS on and now the widget have the same state as before but work without page reloading, then throw in some saving to the server + WebSockets to sync between multiple open browser.... and the next generation of unobtrusive and gracefully degrading ARIA's is born.
Original Answer
Well go ahead and built it yourself then.
Seriously, 90% of all WebApps out there work fine with a REST approach, of course you could do magical things like superior user tracking, tracking of downloads in real time, checking which parts of videos are being watched etc.
One problem is scalability, as soon as you have more then 1 Node process, many (but not all) of the benefits of having the data stored between requests go away, so you have to make sure that clients always hit the same process. And even then, bigger things will yet again need a database layer.
Node.js isn't the solution to everything, I'm sure people will build really great stuff in the future, but that needs some time, right now many are just porting stuff over to Node to get things going.
What (IMHO) makes Node.js so great, is the fact that it streamlines the Development process, you have to write less code, it works perfectly with JSON, you loose all that context switching.
I mainly did gaming experiments so far, but I can for sure say that there will be many cool multi player (or even MMO) things in the future, that use both HTML5 and Node.js.
Node.js is still gaining traction, it's not even near to the RoR Hype some years ago (just take a look at the Node.js tag here on SO, hardly 4-5 questions a day).
Rome (or RoR) wasn't built over night, and neither will Node.js be.
Node.js has all the potential it needs, but people are still trying things out, so I'd suggest you to join them :)
The closest thing is likely Dav Glass's experimental work using node.js, express and YUI3. Basically, he explains how YUI3 is used to render markup on the server side, then sent to the client where binding to event and data occurs. The beauty is YUI3 is used as-is on both the client and the server. Makes a lot of sense. The one big issue is there is not yet a production ready server-side DOM library.
screencast