One language everywhere

Back in the ASP days, we used to use JScript on the server and JavaScript on the client as well as VBScript on both.  It was kinda nice, but the environments and concerns were so different that it usually led to more confusion, not less.   IMHO, having the separation actually helps keep things straight in your mind. When I’m on the server, I use C#/Ruby/Java/whatever and I think in that mode. When I’m on the client, I use JavaScript and I think in that mode (DOM, jQuery, etc).

I’m exploring Node and Mongo DB in a side project. So far I really enjoy using the same language for my DB interactions as the rest of my code. Some things are made dead simple by this, such as accepting JSON input in your API, munging it and pushing it through to your DB. This is so much fun since it is native JavaScript all the way through.

UI doesn’t feel like a big deal here since JavaScript in the UI layer is the norm. I suppose you could mean EJS as a templating language, though there are lots of alternatives in that area.

I work for Sencha and coding entire applications in JavaScript is what we do all the time. I would say it’s 100% feasible based on my experience.

hejdig.

I did just the same and also felt more confusion, not less, by having the sam
e language. There was no help by the enviroment.

On the other hand – I feel no need to change language businesslayer-datalayer.
But I would like more visual help, like code background changing colour between layers.

/OF

Done it many times with Silverlight (C#) and ASP.NET/MVC (again, C#). I’ve not found that it’s the multiple languages that cause issues as much as having to use multiple IDEs for development/debugging, especially when one IDE is far more ‘productive’ than the others). Visual Studio 2010+ is great for web server & client (C#/JavaScript).  

I’ve been doing something similar to Joshua, and I agree about the transfer of data using JSON. Love it. The only negative for me is that occasionally I’ll be in a file and think “Oh, is this client or server?” Still, that’s a small negative.

Oh, I should add I’m using Jade for my view engine, so it’s JavaScript, JavaScript, JavaScript.

Does putting HTML and JavaScript inside the database count?

I think it has a lot to do with the runtime environment.  I don’t suffer from any cognitive dissonance writing stored procedures in some SQL flavor, server code in Java or C#, and client code in HTML + JavaScript, and I think it’s because the runtimes, libraries, architectures, etc. for each layer are entirely different.  If the paradigms and architectures at each level were similar, then developing in different languages at each layer might bother me – but compared to the mental context switch required to move between each layer, making the context switch to a new language is comparatively easy.  Each language is well-suited for the layer in which it’s used, and I think that’s the important thing.

I believe this approach to be fundamentally flawed but, if you must, then take a look at clojure.

On a tangent, the difference between developers and engineers is in attitude. A developer believes in the swiss army knife approach to toolsets and wants to show the world how clever he is that he can make his favorite coding language do things way beyond its original scope. An engineer believes in the right tool for the job. Engineers don’t identify with any single programming language. Instead, they pride themselves on knowing how to code in lots of different environments and API stacks.

But it will confuse lesser programmer….. They will not know when and where each chunk of codes will be run…. and use the wrong variables at the wrong place, and will have a hard time debugging.

I once tried to teach students that they can use php to generate a javascript file that can be sent to the browser, and the javascript can be used to generate html contents.

Then immediately, all of them got confused.

Even if I have oportunity to write code using server side JScript I prefer not to it due to lack of JS type safety . I don’t believe in writing serious commercial code using script languages.

Totally agree with this: I’m torn between liking to be able to use one single language across client and server (it enables some interesting scenarios) and the dreadful perspective of a monoculture. The problem is not that it’s JavaScript (I kinda like it), it’s that there is only one: we need diversity to foster innovation. In other words what we need is more languages on the client. Unfortunately I don’t think Google or anyone else can pull that one off anymore.
So the thing I started doing years ago with prototypes of server-side Javascript is do initial server rendering of templates that also work on the client. Only one template to manage, good seo and ajax behavior.

Right, but take the view code: it’s relevant on both client and server, so there are benefits in unifying them.

UIs and server sides were coded in the same languages for decades. win16 and win32 apps. command line apps on dos, unix, etc. Delphi and then dotnet apps, VB apps, etc, etc.
There was never any major issue caused by langauge choice, but you can gain by building certain sections of your app in a language that is targetted at that modular section.

Alot of people have tried to do this. The success depends much more on how good the language is, and how it implements the patterns necessary to build the assets of your architecture. If I have to use 3 languages but each of them are perfect for their respective responsibility, I have no problem with it. That’s not to say one language couldn’t work everywhere though.

Ever  heard of http://www.jaxer.org ??
everything is written in javascript and code is “flagged” to either run on serverside only or clientside only or both, etc.  works fully with jquery type libraries as well.  Actually all rendering is done serverside I think and only the resulting html/css/js is sent downstream after the jaxer preprocesser works it all out.

Hey Dru – I actually did this this weekend for givecamp, I’ll blog about it later today for you

nice, let me know.