Develop Reference

Django or Ruby on Rails, which one is better for web 2.0 heavy ajax app? [closed]

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 11 years ago.
I want to build a heavy ajax web2.0 app and I don't have javascript, django or ruby on rails. I have some experience with python. I am not sure which one to choose. I have a backend database and have to run few queries for each page, no big deal. So, I am looking for a choice which is quite easy to learn and maintain in the future.
Thank you

I'm not sure if this meets the guidelines for a valid question on here.
If you know any Python go with Django, if you know any Ruby go with Rails.
From my understanding Rails is a bit more opinionated when it comes to JavaScript. In other words it comes bundled with a bunch of helpers to make it simpler to Ajaxify your code. Django on the other hand leaves it up to you to choose your own framework. (Note: I'm no expert on Django, but have been informed as much)
Rails comes bundled with Prototype, works equally well with jQuery and in the master codebase they have already switched jQuery to be the default in preparation for the next release.

ROR has much better community activity. It's easier to learn without learning ruby (i do not recommend that way, but yes - you can write in ROR barely understanding ruby).
About performance: ruby 1.8 was much slower than python. But maybe ruby 1.9 is faster.
If you want to build smart ajax application and you understand javascript it does not matter which framework you will use. If not or you are lazy - ROR have some aid to ajax requests. Also take a note about django /admin/ :)

We've had a blast developing with Django/Jquery, and development, in our opinion, is easier, faster. That being said, we tend to go with Django because of Python's raw power and reliability. Not to say ROR doesn't have similar strengths, but we get "stuck" more often than not when using ROR than when using Django.
If it's a small-ish web app and you're not worried about production deployment on a significant level then go with ROR. If you're looking for something better equipped, more reliable and more conducive to development then go with Django.
Keep in mind, though, that this all boils down to what you know, what you're most comfortable with. If you know a bit of Python go with Django, but know that Ruby is just as easy to pick up if you'd rather go that direction.
They're both win/win really.

If you like Rails but want to stick with Python, you might also consider web2py, which is probably the Python framework that is the most like Rails (it was inspired by Rails, as well as Django). Ajax is particularly easy in web2py -- it comes bundled with jQuery, the scaffolding application includes a lot of built-in Ajax functionality, and you can build pages from components that operate via Ajax.
I think you'll find that web2py is even easier to learn and use than Rails and Django. It's very quick to get started -- just download, unzip, and run it. It requires no installation or configuration and has no dependencies. There's a very helpful mailing list if you have any questions.

Can anyone suggest a good client-side architecture and structure for large scale web applications? [closed]

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 3 years ago.
Improve this question
I'm building a large scale web application. It will grow in the future so I need a good back-end and front-end architecture for my application. at the back of the site, I use Zend Framework so the architecture is OK for me. But at the front, working with javascript and ajax without having a good architecture makes later changes hard and confusing.
For now, I'm using my own architecture. I have a big object for the whole application say BigObject. I extend it when modules are added to the site. say I have an upload module. I use this:
BigObject.upload={
//initialization
init:function(){
},
//I tried to use what I named semi-MVC architecture!!!
controllers:{
//index is a controller
someController:{
init:function(){
//initialization
},
someAction:function(){
//Code goes here
//call a model if necessary
//call view script
BigObject.upload.views.someController.someAction();
}
}
},
models:{
//models required for this module like loading contents with ajax.
loadContent:function(part,callback){
}
}
views:{
init:function(){
//initialize view
},
someController:{
someAction:function(){
}
}
}
}
What do you think? Is there any better solution to this problem? anyone thought about a good structure for front-end part of web applications ( like what we have at back-end,good file structure and object-oriented methods )?

The most up to date answer to this question in 2020, would be to use React + GraphQL + Styled-Components. The best place to start with React is the official Create React App tool. Their are a few different implementations of GraphQL; on the client side the clear leader is Apollo. On the server you have a lot more choice and it is reasonably easy to even roll your own server implementation, so go with what work best with your current backend. Styled-Components gives you CSS in JS, in the same way that React gives you HTML in JS.
For a more complete and opinionated experience, take a look at Gatsby, which brings all of the above into a single framework.
Over the last couple of years a more functional style to writing JavaScript has become popular. If your not used to functional programming then it can be a bit of a steep learning curve to start with, but start by leaning about a library called Ramda.
Here are few links to get you started on functional JS
An introduction to functional programming in JavaScript
Thinking in Ramda
Indentation is the enemy: Writing less complex JavaScript
Mostly Adéquate guide to functional programming
When it comes to testing, then Jest combined with Enzyme is by far the best current option.
Finally for a much deeper answer, checkout this talk from Cheng Lou on the Spectrum of Abstraction.

Most of the answers are proposing stuff like jQuery, React, Angular, Vue.js... which are not frameworks, neither architectures. All of these libraries are layers on top of JavaScript. I just remind you that JavaScript is already a high level language!
Since the question is about a good client-side architecture and structure for large scale web applications, I would say that none of the previous answer solve the problem, and there is a reason for that :
There is currently no emerging or commonly accepted architecture for front-end JavaScript source code organization.
I already read dozen of blog posts, Stackoverflow questions, Youtube videos... I never found someone who detailed a generic, general and scalable architecture. The main reasons are:
front-end JS code is quite small regarding back-end source code, most of the developers do not need a scalable architecture.
execution is ephemeral, lifetime of JS is the same as web pages lifetime.
the problem for many developers is more about manipulating the DOM than structuring large JS code. This is why people answers are about libraries rather than frameworks.
I really expect that some day, someone will propose the first real JS architecture (like MVC for example). But in my opinion, this architecture will be more about event-callback than MVC. Before concluding, I'll suggest you the following ressources:
Imperative or procedural programming.
Functionnal programming (probably the best lead with modules)
Awesome videos of Fun Fun Function
JavaScript modules
To conclude, I'll strongly recommend to consider JS modules that have a great underestimated potential. This is not exactly an architecture, but:
JS modules organise your code
JS modules are scalable
maintanability is easy
JS module are reusable
Previous list isn't the main reasons why you need to organize your code?
Word to the wise!

A lot of people push for either Dojo or YUI for large applications. They are honest frameworks where most everything else you'll find is a library.
Personally, I tend to stick with jQuery. I create jQuery plugins or jQueryUI Widgets as needed. I've managed to push jQueryUI pretty far.
Everything falls in either $.fn.myPlugin or $.ui.myWidget. To me, this has the added benefit of pushing you to keep code very modular and portable (assuming you abide by jQuery/jQueryUI conventions).
$(element).myWidget({
color:'eggplant',
someValue:42
});
$.upload(args);

I was actually struggling with the same question for sometime.. after doing few large-scale projects, I thought of sharing my learnings as a reference architecture incase someone else finds it useful.
Have a look at http://boilerplatejs.org. It is not a library, but a framework that integrates some industry leading libraries with architectural patterns for large scale javascript development.

According to my understanding on the frontend i will ask you to use web-components that uses only HTML,CSS and JS.
No need to spend much time on understanding the other languages. If you take the latest UI frameworks or libraries like Angular, React they have built on web components.
You can customize your own components and use cases which you want to use in your project.When you are using frameworks it will take some time to load and follow up for few libs that are using.
JS you can use it any way you want. You can re-use these components in any number of projects once you have created.
Just look into webcomponents https://www.webcomponents.org/introduction you will get a clear idea. I hope this helps.

With the experience of scaling some of my content for million viewers in my application. But then I had to close the application for less profit and more stress in managing it (not the cost though, but the profit was not high enough to keep up motivation)
My architecture was:
Mithril.js.org library - Checkout mithril here for front-end
Twitter bootstrap front-end framework
Backend with "Laravel and started migrating some of the heavy write data to nodejs"
Redis as in-memory storage.
I was almost in a situation to move my storage to s3 before I shut down the app.
No jQuery - I kept my app jQuery-free ( I heard and read somewhere big app avoid jQuery, so without further investigation myself, I planned to remain jQuery-free as well, though I have no solid or bullet proof reason to avoid jquery)
I found mithril more interesting then react or angular, it was so easy to start and I was building while I was learning, it was damn easy and they claim, they are better than react, vue and angular in terms of size and performance.

My response would be to ask why you need this? I've worked on plenty of applications which make use of javascript, but one thing that I've learnt is that the best thing to do is to minimise javascript and most especially object orientated javascript to an absolute minimum. Web pages with large and complicated javascript tend to be slow, memory hungry and a pain to debug with all the browser variations.

Comparing YUI and Ext JS [closed]

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've been using Ext JS as my rich-widget toolkit for a while, but I'm thinking of moving to YUI, partly because of the less restrictive license.
The component-oriented model used in YUI seems quite similar to the one that I've enjoyed so much in Ext JS, but I'm interested in how deep those similarities are. So I'm interested in feedback from people who've used both Ext JS and YUI. What is the same, and what is different? What do I lose by moving to YUI, and what do I gain?

I think both libraries actually address different needs.
YUI is designed addresses the needs of Yahoo inc. It is very good at building public facing applications where things like graceful degradation, clean markup and accessibility is important.
ExtJS is a very good and well designed full RIA framework that is very firmly targeted at building line of business applications. Features such as a really powerful grid component, strong layout and good professional look and feel.
I've used both quite considerably, although only up to YUI 2.7.0 and have built several full RIA using the frameworks.
Moving an existing application from one to another would be quite differcult as although they share a common ancestor (ExtJS was once YUIext) the frameworks are quite different now.

One major difference is that YUI is distributed under the extremely permissive BSD license whereas ExtJS is distributed under a very viral interpretation of the GPL. For instance, with Sencha's interpretation of the GPL, if you write a SOAP or REST interface specifically to talk to an ExtJS front end then your server code must be GPL and you must provide access to the source since you have "distributed" it by granting access over the web. Sencha does provide a commercial license for their code but if you read their docs carefully you will see that they do not allow you to convert code you wrote against GPL Sencha to another license when you switch to the commercial version. (http://www.sencha.com/legal/license-overview)
In short, if your code needs to integrate with proprietary business logic or commercially licensed systems then you must develop using the commercial version of Sencha from the outset.

For me the difference is that YUI is very lightweight and flexible, whereas ExtJS is heavier, with a bigger footprint and more rigid in the way you use it. YUI is great if you know what you're doing in Javascript and want to extend your power; ExtJS is good if you want a UI abstraction layer that you don't have to mess with much ... but if you do want to make it do things it wasn't designed to do, it can be a real chore.

When building a recent application I had the exact same decision to make YUI or Ext JS.
I ended up going with YUI for a few reasons:
YUI 3 is extremely light weight and fast for simple tasks and the lazy loading makes things even faster.
Graceful degradation was important for this app.
Using YUI 2 widgets in YUI 3 is rather easy and with 3.1 literally weeks away that will become even easier.
YUI documentation is unbelievable and the irc chat and forums are very helpful and actually have people from the YUI development team.

In a time when all applications are migrating to the web, the clear line drawn by Gareth between public facing and Business app doesn't make sense too me.
I prefer the other answers, like the one of Robusto, and compare both framework on technical/financial grounds.
YUI advantages:
Free
Lightweight (HTML + Javascript)
More efficient
Easier to learn and understand
Better documentation and examples
Larger community
Ext advantages:
Richer features & components
Some (undocumented) Server Side driver (like .NET) (although using such libraries on the server seems bad design)
Conclusion:
If your web site doesn't require the extra features provided by ext, go for YUI.

I haven't used ExtJS a lot yet, still in a learning phase, but for what I was able to do with it, I'm pretty sure that even a little more than 1 year ago when I was doing a lot of YUI dev, it would have been much more challenging and the result would not have been as slick.
It's not too say you shouldn't do it, but my advice to you would be to make some serious research and good prototyping of some of the existing features you have to see if YUI will fit your needs. DON'T just base yourself on the examples and the feel of "Yeah seems that would work".

With the GPLv3, it states that as long as your users are all part of the same legal entity that you do not need to share the source code. The verbiage technically states this as if they are not part of the same legal entity, then you need to provide source. But this doesn't mean Sencha won't change the license later. It also doesn't mean they will either.

What are the arguments against using a JavaScript Framework for a Web site development company? [closed]

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 3 years ago.
Improve this question
Our company builds websites and web applications. We are a small firm and our team of developers are always building the javascript functions from scratch or copying from other websites built by us. Every time I bring to the table the word standardization and using a JS framework like JQuery, Prototype or any other, I am told Frameworks have the three points below as arguments against them:
Mainly for people that don't know enough JS
Frameworks limit Javascript developers
Frameworks bloat the actual development code with a lot of things that are not used.
We don't use enough Javascript in our applications for us to need JS framework
In my mind it seems that Frameworks, give our team a good starting point, documentation, a community and always the option to grow on top of the framework. Could some Framework users elaborate further?
EDIT 1:
Thanks to all of you for your great responses. I really did not think that this was going to be such a hot topic. I am glad I asked the question. I posted another similar question in the following link in case you might think you want to add something. The topic of the new question is CSS related. Thanks.

By your coworkers point of view, .NET and JAVA are for people who don't know enough assembly.
Frameworks exist for a reason. They allow you go focus on the problem instead of dealing with repetitive code. They allow you to be confident (assuming you use well tested frameworks) that certain pieces of your code are reliable and well tested.
If your coworkers are against frameworks, I would seriously consider moving on.

Since no one has mentioned it - a Javascript framework rapidly becomes one more project dependancy, and in general terms, dependencies are bad as they represent points of failure.
As for this:
Mainly for people that don't know
enough JS
Without elaborating, I will say that if one of our team said something like that in my presence, I would try to shrug it off as a joke. If I thought they were being serious, I would probably have to kill them.
And as for this:
Frameworks limit Javascript
developers
That could translate to "Frameworks make it marginally harder to write spaghetti code, and that's what I do best"
Those are not arguments, they are excuses.

Arguments against:
Frameworks prevent you from re-inventing the wheel
Frameworks generally contain well tested code
Frameworks are well supported by the community
Frameworks force you to focus on the business problem you're trying to solve
</sarcasm>
Frameworks may have a license you don't agree/can't work with

A few positives for javascript frameworks (like JQuery).
They provide standardization in ui
elements.
Reduce time to develop complex
interfaces and effects.
Normalize efforts by providing
functions that are already
cross-browser compatible.
Due to efforts in cross
compatibility documentation is more
useful in a framework as you can use
the framework's api as canon
instead of searching for obscure
support for various/proprietary
javascript functions.
Reduced learning curve for new
developers making them productive on
your software quicker.
I completely disagree that a framework limits javascript developers. Quite the opposite actually. Most frameworks provide extensive plug-in mechanisms where the framework can be extended using raw javascript utilizing hooks in the framework itself.

I'll use jQuery as an example, but what I'm saying here could apply to most JavaScript frameworks.
Many frameworks (notably jQuery) are far too monolithic and not modular enough.
While depending on well-tested 3rd party software is often more than justified, "frameworks" tend to give you a lot more functionality than you need at the moment.
In many projects, I very much like the convenience that jQuery gives me for selecting sets of elements (using $(".classname"), for example). But, if I'm not using any significant amount of AJAX, I don't need the AJAX utilities provided by jQuery.
Software should do one thing and do it well, and software written in JavaScript is no exception. Most of the frameworks you refer to try to do everything, resulting in unnecessary complexity.
One place this can bite you is when you're considering upgrading to the next version of the framework. That involves crawling through jQuery's changelogs for backwards-incompatible changes and searching your project for areas where that code is used. This can be quite a nightmare, especially if you don't necessarily have a comprehensive list of which jQuery features you use and which ones you don't.
Also, jQuery (and other frameworks) tends to cause developers to start depending on new features of jQuery without even thinking about it, making it harder to determine which features of jQuery your project uses and which it doesn't.
If you use a utility which does one thing, then you know exactly which features of that utility you're using. There's only one. (If you aren't using that utility at all, it's easy to determine. Such a determination would mean you could safely remove it from your project.)
I'm all for using well-tested 3rd party code. But if it tries to do too much, (that is, if it's a framework rather than a utility), you should probably look for an alternative. If it tries to do too much (like jQuery tries to do too much), then it's got some serious, foundational design flaws that will probably come back to bite you.

I'm surprised no one has already mentioned it:
A lot of web developers default to using JQuery without considering the alternatives
And end up including it on a web page to do a few trivial tasks which could easily be done in pure JavaScript
The result is that users have to wait for the whole library to download and it slows down web browsing
Also:
Some web developers get carried away with the design of web pages, and end up developing unnecessarily complex web pages because of the power of JQuery
Just because JQuery enables you to create scripts with good cross-browser compatibility it doesn't mean that the end result is usable on different devices / interfaces
I'd also argue the cross-browser compatibilty because I've seen instances of webkit not playing well with JQuery
JQuery encourages "fast" scripting - but if you rush it you are likely to have missed something out
Writing in JavaScript from scratch is slower - but I believe that you end up with a more complete solution which more closely matches the users needs
Using JQuery can shift the focus of the web developer to creating web sites which are highly graphical and visually appealing, whereas the focus should be on functionality and usability
JQuery is not a silver bullet for web development
I am biased here because I don't use JQuery, but it is because I haven't found a need for it yet - maybe it's because I focus more on usability and functionality rather than making the user interface look pretty (sorry I know JQuery can do more than that).

An argument against libraries is BROWSER SUPPORT most libraries support only a subset of browsers out there .
Here is an example of BBC rolling out their own instead of using something like jquery .

I liked the answer of pb +
Mainly for people that don't know
enough JS
I believe it is too complicated for them, so they use this excuse. FW allows you to build much more complex applications.
Frameworks limit Javascript developers
bullshit
Frameworks bloat the actual
development code with a lot of things
that are not used.
what is it today extra 100k-200k? especially if you use the CDN versions (at google for instance). And this is assuming you use nothing in the FW.

There are plenty of good reasons to be suspicious of frameworks in general, balanced of course by lots of reasons why they are worthwhile.
I use jquery now, and frankly within an hour of learning it realised that it fits the job so well that if it didn't exist I'd only end up reimplementing something very similar myself, only it wouldn't be as good or as cross platform.
There isn't much bloat there, it's very small and well designed and does nothing at all that stops you writing any javascript you want for specific cases that don't fit your needs.

Will server-side JavaScript take off? Which implementation is most stable? [closed]

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.
Does anyone see server-side JavaScript taking off? There are a couple of implementations out there, but it all seems to be a bit of a stretch (as in, "doing it BECAUSE WE CAN" type of attitude).
I'm curious to know if anyone actually writes JavaScript for the server-side and what their experiences with it have been to date.
Also, which implementation is generally seen as the most stable?

I like to read Googler Steve Yegge's blog, and recently I came across this article of his where he argues that Mozilla Rhino is a good solution for server-side JS. It's a somewhat sloppy transcript, you might prefer to watch the video of the talk. It also offers a little bit of insight on why he thinks server-side JS is a good idea in the first place (or rather, why he thinks that it's a good idea to use a dynamic language to script Java). I thought the points he makes were convincing, so you might want to check it out.
A while earlier, he also posted something about dynamic languages in general (he's a big fan of them), just in case you were wondering why to use JS at all.

Why would you want to process
something in Javascript when you can
process it in PHP or ASP.NET which are
designed specifically for this task?
Perhaps because JavaScript is a more powerful programming language than those two? For example, it has functions as first-class data types and support for closures.
Steve Yegge has blogged about porting Ruby on Rails to server-side JavaScript as an internal project within Google ("Rhino on Rails"). He did it because he likes Rails but using Ruby isn't allowed within Google.

Before it was acquired by Google, JotSpot used server-side JavaScript to let you query their database and display your pages. They used Rhino to do it. CouchDB uses server-side JavaScript to create views of their database.
As you can see from these examples, a great way to use JavaScript on the server is for plugins. One of the reasons it's used is that you can create a very isolated sandbox for people to run their code in. Also, because of the way that JavaScript as a language works, you can provide a user tooling specifically honed to the tasks your users need to complete. If you do this right, users don't need to learn a new language to complete their tasks, a quick glance at your API and examples is enough to get them on their way. Compare this to many of the other languages and you can see why using server-side JavaScript to provide a plugin architecture is so enticing.
A secondary popular solution, one which can be seen through a project like Jaxer, is that a common problem of web applications that do client-side validation is that, since JavaScript is easily bypassed in the browser, validation has to be run once again on the server. A system like Jaxer allows you to write some validation functionality that is reusable between both server and client.

Support for JS on the server has been getting stronger and the number of frameworks is getting bigger even faster.
Just recently the serversideJS group was founded. They have a lot of smart people that have been working on serverside JS for years (some of them more then 10).
The goal for this project is to create
a standard library that will
ultimately allow web developers to
choose among any number of web
frameworks and tools and run that code
on the platform that makes the most
sense for their application.
to the people who say "why would you choose JS over java or any other language?" - you should read this Re-Introduction by Crockford and forget about the DOM - the DOM is superugly, but that's not JS fault and JS is not the DOM.

I've never even heard of this, but it strikes me as using the wrong tool for the job. Since programming languages are just tools designed to help us solve some problem.
Why would you want to process something in Javascript when you can process it in PHP or ASP.NET which are designed specifically for this task?
Sure you can pound a nail in with a screw driver, but a hammer works much better because it was actually designed for it...
So no, I don't see it taking off.

Well, plain ol' ASP supported JavaScript server-side years ago and everyone onad their dog used VBShiate instead. But I have to agree with the others: JS does not seem to be the right tool here - and I love to do client-side JS :)

I personally did a whole site in server side JavaScript using ASP. I found it quite enjoyable because I was able to have some good code reuse. This included:
validation of parameters
object modeling
object transport
Coupled with a higher-level modeling tool and code gen, I had fun with that project.
I have no numbers on perf unfortunately, since it is used only on an intranet. However, I have to assume performance is on par with VBScript backed ASP sites.

It seems like most of you are put off by this idea because of how unpleasant the various client-side implementations of Javascript have been. I would check out existing solutions before passing judgment, though, because remember that no particular SS/JS solution is tied to the JS implementations currently being used in browsers. Javascript is based on ECMAScript, remember, a spec that is currently in a fairly mature state. I suspect that a SS/JS solution that supports more recent ECMA specs would be no more cumbersome than using other scripting languages for the task. Remember, Ruby wasn't written to be a "web language" originally, either.

Does anyone see Server-side Javascript
taking off?
Try looking at http://www.appjet.com a startup doing hosted JavaScript applications to get a feel for what you can do. I especially like the learning process which gently nudges the user to build things with a minimal overhead ~ http://appjet.com/learn-to-program/lessons/intro
Now it might seem a weird idea at the moment to use JavaScript but think back when PC's started coming out. Every nerd I knew of was typing away at their new Trash-80's, Commodore64's, Apple ]['s typing in games or simple apps in BASIC.
Where is todays basic for the younger hacker?
It is just possible that JavaScript could do for Web based server side apps as BASIC did for the PC.

XChat can run Javascript plugins.
I've some accounting software completely written in Javascript.
There's this interesting IO library for V8: http://tinyclouds.org/node/
CouchDB is a document database with 'queries' written in Javascript (TraceMonkey).
Considering this, i believe, server-side Javascript did take off.

Server-side programming has been around for a lot longer than client side, and has lots of good solutions already.
JavaScript has survived and become popular purely because developers have very little choice in the matter - it's the only language that can interact with a DOM. Its only competition on the client side is from things like Flash and Silverlight which have a very different model.
This is also why JavaScript has received so much effort to smart it up and add modern features. If it were possible for the whole browser market to drop JavaScript and replace it with something designed properly for the task, I'm sure they would. As it stands Javascript has strange prototype-based objects, a few neat functional programming features, limited and quirky collections and very few libraries.
For small scripts it's fine, but it's a horrible language for writing large complicated systems. That things like Firefox and Gmail are (partly) written in it is a heroic accomplishment on their part, not a sign that the language is ready for real application development.

Flash Media Server is scripted by using Server Side Action Script, which is really just javascript (ECMAScript). So, I do it a lot. In fact, most of my day was dealing with SSAS.
And I hate it. Though to be fair, a bunch of that is more related to the (not so great) codebase I inherited than the actual language.

I think server-side Javascript is guarenteed to take off. Its only a matter of time.
Mozilla, Google, and Adobe have so much vested interest for Javascript that it would take a miracle to dislodge it from the browser world. The next logical step is to move this into the server-side.
This is a step towards moving away from the hodge podge of Internet technology that usually includes all of these
HTML
CSS
Javascript
Serverside Language J2EE/ASP/Ruby/Python/PHP
SQL
I haven't heard much about the current state of Javascript Server frameworks, except that they are mostly incomplete.

I see server-side js will offer considerable advantages in future applications. Why? Web apps that can go offline, client-side db store, google gears, etc...
Following this trend, more and more logic are moving into the client-side. Use an ORM that works for client-side, and use another on server-side (be it PHP / Ruby / whatever), write your synchronization logic twice in two different languages, write your business logic twice in two different languages?
How about use js on the client AND the server side and write the code once?
Convincing?

Personaly i've been developing and using my own JavaScript framework for about 4 years
now.
The good thing about JS on serverside is that implemented in ASP Classic you don't need
any other plugin or software installed, besides i'm also using my javascript (client)
framework on my server, that allows me to enjoy of the same functionality and proven
performance of my functions at both environments client and serverside.
Not only for data validation, but also lets say HTML or CSS dynamic constructions
can be done client or serverside, at least with my framework.
So far it works fast, i have nothing to complain or regret except its great usability
and scalability that i have been enjoying during this past 4 years, until the point
that i'm changing my ASP Classic code to javascript code.
You can see it in pratice at http://www.laferia.com.do

Node.js has taken off and proven that server-side JavaScript is here to stay =)

I can't see most developers getting over their distaste for client-side JavaScript programming. I'd rather go to Java for server-side stuff before choosing JavaScript.