A Sudden Move: One developer's journey from C# to JavaScript

JavaScript is 'tragically important' because, although it is inherently flawed, it is used everywhere because it allows the developer to use the same language for a variety of platforms and purposes. At last, the uniformity of browser and Javascript standards give the promise of code that really is 'write once, run anywhere'

Why JavaScript, why now?

Earlier this year I left the comfortable world of XAML and WPF behind and began developing almost exclusively in JavaScript. My daily focus has also switched from developing desktop applications to Single Page Applications (SPAs) using ASP.NET MVC and KnockoutJS: but, as we’ll see, JavaScript does not restrict me to web development.

I was discussing this change of direction with a good friend of mine and he asked whether that wasn’t a little extreme. I suppose it would certainly seem that way, especially for someone who has made a name for himself in the XAML community. I would not make such a drastic change lightly. I thought long and hard before making the move and, after twelve years in one place, I even changed jobs to facilitate the effort. I thought it would be worthwhile to share some of my reasoning behind this latest change of direction.

Not long after I had made the switch, I had the pleasure of hearing Douglas Crockford speak at a conference. Mr. Crockford, as most people insisted on calling him, is the author of “JavaScript the Good Parts” (by O’Reilly), JSLint, and JSON, and is a member of the ECMAScript Standards body. I’ll never forget the quote he made that “JavaScript is tragically important”. My one line take on this is that, for all its faults and foibles, JavaScript cannot be ignored.

JavaScript is ubiquitous. Every PC, Mac, laptop, tablet, slate, netbook, ultrabook, and smart phone that is out there in the wild today runs JavaScript. It’s already there, it’s already installed, and it’s amazingly consistent across the different operating systems and devices. It took a while for me to realize that JavaScript comes closer than either Java or .NET to fulfilling the old promise of “write once run anywhere”. If for no other reason than universal reach, JavaScript is a serious language.

The ubiquitous nature of JavaScript means that the pain of framework and platform deployment is a thing of the past. The browser is the platform, the Internet is the deployment model. Thanks to the browser manufacturers there are no frameworks to deploy, no installers to execute, no administrator permissions issues, and virtually no versioning issues. Regardless of your personal feelings about JavaScript it is undoubtedly the single most important computer language in the world today.

JavaScript: it’s not just for browsers anymore

In recent years the reach of JavaScript has begun to extend beyond browsers and the Internet. Thanks to projects like Node.js JavaScript is now being used to develop server applications. These applications have no Document Object Model (DOM) and don’t run in the browser: they are real server-side applications. The introduction of headless unit testing tools, such as PhantomJS and Zombie.js, built on Node, demonstrates that you don’t have to have a browser to run JavaScript.

For Windows 8, Microsoft made an unprecedented move and elevated JavaScript, HTML, and CSS to a first class development stack for creating Windows Store Applications. This is not some specialized version of JavaScript: these applications leverage the same Chakra engine that runs inside IE10. That means you can use the same JavaScript you use for web applications to develop Windows Store Applications, including the use of third party libraries. This move makes it conceivable for web developers to create Windows Store Applications using the same core technologies they code with every day which reveals the true reason I decided to become a JavaScript developer: I now have a single technology stack that allows me to develop for the web, servers, and even Windows.

I’ve been asked several times recently, in the context of Windows 8 development, which stack a developer should select. My answer is simple: if you already know XAML and C#, then that is the obvious choice. If you are a web developer and already know JavaScript, HTML, and CSS, then that is the obvious choice. But what if you don’t know either? Maybe you’ve only done WinForms or FoxPro development, what then? The hands-down winner is JavaScript. I believe that, in the current state of technology learning, JavaScript is the best investment you can make for your career. In fact, I believe that, in the near future, JavaScript will be an essential tool in virtually every developer’s toolbox.

But everyone hates JavaScript

I’ve heard many developers say “I hate JavaScript”. In the spirit of full disclosure, I’ve said it myself any number of times. Most people who have encountered JavaScript have felt this way at one time or another. What I’ve come to realize, however, is that we unfairly blame JavaScript for things that are not its fault.

A lot of developers first encountered JavaScript during the browser wars when it was a significant challenge to develop websites that worked equally well across the different browsers. If you don’t remember web sites with “Works best in IE” badges, count yourself lucky. The good news is that the wars are largely over. The bad news is that nobody won, it is more of an uneasy truce. Any experienced web developer will tell you that DOM manipulation stinks, but we should not blame JavaScript for the shortcomings of the DOM API.

JavaScript is a wolf in sheep’s clothing. It is a functional, dynamic, loosely typed language with a C-inspired syntax. The visual similarity to languages such as C# and Java is unfortunate because it misplaces developer expectations. At first glance it looks as if curly braces should define scope, that “this” should refer to an instance of a class, and that “==” means equality. None of these things are correct. The problem is that as developers we expect JavaScript to function like Java or C#, and we are often surprised by the differences. Because it is so easy to make incorrect assumptions about its behavior from its syntax, and because the language is so flexible, it is very easy to code one’s self into trouble. This is not the fault of JavaScript but rather our own flawed expectations. To overcome this issue, we must embrace what JavaScript is instead of lamenting over what it is not.

Before I get a slew of messages telling me about all the stuff that’s wrong with JavaScript, I am not saying that it doesn’t have its difficulties, or as Mr. Crockford would say “bad parts”. Like any language, it’s up to us developers to learn how to use the language effectively. This can be a painful process, again largely because the syntax looks so similar to the languages we know and love. I believe that, if you invest the time to become familiar with it, you will find JavaScript to be a flexible, powerful, and very usable language.

The importance of 3rd party libraries

Modern developers have become accustomed to frequent and volatile shifts in technology, but JavaScript has largely escaped this phenomenon. While JavaScript has been around for nearly 20 years, it has only had a handful of major updates. ECMAScript 3 (ES3) was published in 1999, skipped a version, and ES5 was published in late 2009. This stability is a welcome change from the frenetic pace of most other technologies. It is also an understandable necessity: JavaScript can’t afford to move fast because of the sheer number of websites and applications that use it. A breaking change in .NET is inconvenient for the developers, but a breaking change in JavaScript would have disastrous implications across the Internet.

This isn’t to say that the JavaScript ecosystem is stale, in fact it’s quite the opposite. Third party libraries have improved the JavaScript development experience dramatically by abstracting away many of the more troublesome aspects of developing JavaScript applications. There are many libraries that mitigate things like DOM manipulation, publish/subscribe operations, string manipulation, and much more. And there are new libraries being published all the time. The open source nature of JavaScript development should ensure this trend will continue for some time to come.

Another great point about third party libraries is that including them in your application is only a script tag away. They don’t need to be compiled into your application and you don’t need to ship DLLs or packages. In fact, you have several options for importing the JavaScript into your site. You can store copies of them locally and deliver them from your server (preferably bundled and minified), you can reference files stored on the publisher’s server, or you can reference a Content Delivery Network (CDN) for optimum performance and availability.

Of course, you don’t need to use third party libraries at all. Anything these libraries can do you can do in plain old JavaScript. Some people even argue that you should not use third party libraries, at least until you learn the language itself. The argument is sound: you should know what a tool is doing before you use it.

Another concern with third party libraries is performance. Performance tests indicate that plain old JavaScript can be up to an order of magnitude faster than third party libraries for core operations such as looping and querying the DOM. In many applications this is almost unnoticeable, but the more complex an application, the more it could benefit from better performance.

Personally, I like the additional libraries, but these are valid concerns. If you want to read more about this, and have a good laugh in the process, check out http://www.vanilla-js.com.

Moving forward

A quick search of any of the major job sites shows that the demand for skilled JavaScript developers is high. This is no surprise given that web applications run on every conceivable device and constantly grow more sophisticated, and the engine that drives those applications is JavaScript.

JavaScript is a vital language. It has power, flexibility, and most importantly, unprecedented reach. You can use it to develop web sites, server applications, and Windows Store Applications. I even recently heard someone say that JavaScript is the new Assembly language.

Whatever your personal feelings about JavaScript, I think the verdict is clear: it absolutely should be in your toolbox. If you want to strengthen your career and enhance your options, learn JavaScript. Who knows, you might even find that you really enjoy it, but just be sure to avoid the bad parts.

  • 43186 views

  • Rate
    [Total: 107    Average: 4.1/5]
  • BuggyFunBunny

    How’s the Kool-Aid?
    — At first glance it looks as if curly braces should define scope, that “this” should refer to an instance of a class, and that “==” means equality. None of these things are correct.

    And that’s because the definers of that language were ninnies. One doesn’t overload/re-define settled syntax; even with good reason. And there is no good reason here. Or, to paraphrase the Red Queen, "words mean what I say they mean."

    — Like any language, it’s up to us developers to learn how to use the language effectively.

    The problem is that much of development is at the behest and direction of marginally clueless Suits, who make decisions in a lemming sort of way. There’s a reason that 99.44% of JS code isn’t restricted to "the good parts". Good luck finding a group that does restrict. And more good luck being a singleton developer doing only the good parts, and having to then interact with the lemmings.

    — but a breaking change in JavaScript would have disastrous implications across the Internet.

    And such is the plaint of COBOL. Come to think about it…

    You go on to say that libraries morph the language pleasantly, but that one should expect stinky performance, so don’t bother with the libraries. Which brings one back to a botched up syntax and semantics. Finally, a few outliers have been pushing server-side JS for decades; the Flanagan book’s first half was pointed that way, and still is. To no avail.

    Remember, the browser is just a 3270 with pretty pictures. It has no other purpose but to show the RDBMS data, take input, provide edits, and send back the data. Using JS, or any language, to implement data logic on the client is not where it’s at. The host/terminal paradigm is resurgent, thanks to big powerful servers and high enough bandwidth to support bi-directional communication twixt the terminal (browser) and host (web thingee). RS-232 in the sky.

  • timothyawiseman@gmail.com

    A compelling case for javascript.
    Thank you for the article. You make a compelling case for javascript. But as with most tools, it is well suited for some things and there are other cases for which other languages are better suited.

    But if I can ask, where would you recommend someone that has little javascript experience, though perhaps experience with other languages, start in learning it?

  • joelcochran

    No kool-aid here…
    @BuggyFunBunny: Thanks for the comments. My point with 3rd party libraries is that some choose not to use them because of performance concerns. I never said to bother with them or not, the choice is yours, just make sure it is an informed one.

    I agree with you about the importance of client/server. I do not, or would not, advocate relying solely on client side logic for business rules for numerous reasons. This article in no way is meant to imply that we should abandon server side logic.

  • joelcochran

    Getting started
    @timothyawiseman – the best place to start would be with the book I mentioned in the article: "JavaScript: The Good Parts" by Douglas Crockford.

    Mr. Cockford also has lots of great videos online for free: http://yuiblog.com/crockford/

    There are lots of free resources online as well. "JavaScript Essentials" is a free ebook available in several places: http://www.techotopia.com/index.php/JavaScript_Essentials

    And you can use tools like JSFiddle.com to experiment.

    Thanks for reading and best of luck!

  • joelcochran

    Getting started
    @timothyawiseman – the best place to start would be with the book I mentioned in the article: "JavaScript: The Good Parts" by Douglas Crockford.

    Mr. Cockford also has lots of great videos online for free: http://yuiblog.com/crockford/

    There are lots of free resources online as well. "JavaScript Essentials" is a free ebook available in several places: http://www.techotopia.com/index.php/JavaScript_Essentials

    And you can use tools like JSFiddle.com to experiment.

    Thanks for reading and best of luck!

  • David Hanson

    Similar decision
    Thanks for this article, I have also reached a point where I am looking to jump from c# to xaml. I still love those technologies but long term I think they are a dead end. I have been impressed with a lot of the JS libraries out there and languages such as typescript which introduce compile time checking is a big win for me as I am not keen on dynamic languages.

    Lets just hope the tooling can catch up/

  • Dave Hanson

    Similar decision
    Correction "I am looking to jump from c#, xaml to JS & HTML"

  • Paul S

    Same here
    I’ve been using c# since 2001 and WPF since the beta, but find that the lack of WPF specific jobs are pushing me towards js and the web stack. I’ve also been (20 years) a pure Windows Client dev, with services and db design/dev.

    Now I’m facing the prospect of learning javascript (the good parts), html5, css plus any number of libraries to stay in the game.

    Looks like a long road ahead…

  • Paul S

    Same here
    I’ve been using c# since 2001 and WPF since the beta, but find that the lack of WPF specific jobs are pushing me towards js and the web stack. I’ve also been (20 years) a pure Windows Client dev, with services and db design/dev.

    Now I’m facing the prospect of learning javascript (the good parts), html5, css plus any number of libraries to stay in the game.

    Looks like a long road ahead…

  • simplycoding

    JS not close there for LOB apps
    Your article doesn’t differentiate between the type of apps being built and to use the right tool for the right job instead of an overarching one size fits all solution. For simple consumer type shopping cart, contact forms, dashboards JS/HTML it’s feasible. Once you start developing complex LOB apps requiring multiple modules, tabs, front end zones, etc. for heavy data entry manipulation keeping JS/HTML working and refactoring becomes a nightmare. Granted there’s movement to make this easier via Typescript, Dart, GWT, etc. it’s still a long way off from being enterprise ready unless you want to go way over budget trying to get something working with JS that you could do in half the time via C#. However, I do agree JS is a skillset to be learned, but using the right tool for the right job is important.

  • ClrJs

    ClrJs alternative
    ClrJs(Common language runtime in javascript) is gwt alternative in .net world. But not finished yet.
    After we complete project, wpf projects can be run on browsers. ClrJs is not a code coverage tool like GWT. ClrJs is an efficent .net il code interpreter.
    Supports Threads , events , reflection Api , and many .Net properties. ClrJs will be published soon.

  • Kwazai

    -scripts -objects -graphics
    Only problem I have with scripts is that the programmer tries to rely on them almost exclusively (at least from what I’ve seen). Particularly with graphics. Letting the script engine ‘draw’ per se rather than manipulating a drawing object and saving the object instead of the script. Its not very conducive to avoiding object errors- the script can be cut and pasted, but may or may not work in a particular order/place (script events being dependent on previous script events occuring ,get screwed up if coordinates change). Ditto script in a browser not working in another browser.
    I looked at three.js recently and it is part of OpenGL (WebGL?) that may eventually be a viable tool for Javascript. Its on my list of ‘toys’.

  • Nevin House

    JavaScript for Windows Phone?
    No question that Microsoft is committed to enhancing JavaScript within Visual Studio and across its development tools. Heard any good rumors about WinJS for Windows Phone? I understand Sencha Touch and jQueryMobile already can be used for Windows Phone development in addition to the usual web projects that concern tablets and PCs.

  • OJ

    JS is crap
    Sorry I read your article as a passer by and felt compelled to respond.

    I am a fairly new school developer, as in just finishing my masters and about 3 years professionally. I work with Java and C# wpf xaml etc.

    I could honestly say I’d rather learn objective C or C++ than Java script and that’s because every single time I have cone across JavaScript I have had issues with it. It is a piece of crap language stiched together and only kept alive because of the browser.

    I hope to God it doesn’t take off in any meaningful way in the enterprise.

    if google/apple have their way this language will be gutted and I think Microsoft is desprate for developers and are making bad decisions left and right. Such as kill Silverlight etc for this piece of crap standard.

    anyway, sorry you make some points but JavaScript is still shit and hopefully it will never take off.

  • Duane Urban

    Interesting
    I’ve been developing for a long time and remember several times in the past where JavaScript on existing websites where broken on new browser versions. Also as far as I know people can still disable JavaScript in their browser.

  • Anonymous

    JS++
    I’ve been using javascript server-side since 2001 after reading Thomas Yager’s Windows 2000 Web Applications Developer’s Guide. It is really nice to write a function once, that works on both the server and client side. Why they may alway be the need for other languages due to hardware limitations, Javascript should be the language of choice for everything else since it is so ubiquitous.

  • Ben

    Don’t underestimate JS
    For what it’s worth, I was in the same position as many of the JS doubters posting responses on here about a year ago. I had been working almost exclusively in XAML and C#, and I thought Javascript was just for kids and I really wanted no part of it.

    That being said, about a year ago my company decided we were ditching Silverlight (because of Microsoft’s decision to kill it), and switching to an HTML5/Javascript client. Our LOB applications are quite complex, and we have a designer that wants everything to be sexy and APPLE like. After pounding my head against a desk for a week, I decided to go with it and start learning JS.

    Now, after a year of developing an app in it, I must say that my feelings have changed completely. JS is powerful (from a developer point of view), easy to maintain and extend (if you organize your code properly), and just downright great.

    There are great 3rd party libraries you should consider using if you are hesitant about JS and come from a XAML world.

    #1 recommendation is jQuery – makes DOM manipulation simple (you can walk up and down elements just like you did in Silverlight/WPF)

    #2 recommendation would be using KnockoutJS – databinding makes the transition from Silverlight/WPF to HTML5/Javascript amazingly easy.

    Another important item is finding a way to organize and distribute your code so that it is easy to maintain and deliver to the client. After looking at a few solutions (like javascriptMVC and some others), we just decided to roll out our own. This was a boon to our development team. We organized our solution just like one would do for any normal MVVM .NET solution – abstracting out the functional parts of code into separate files.

    Thats enough of me blabbing – just thought you guys needed to hear BOTH sides of the story.

  • Robert J. Good

    Strongly typed, compiled languages still lend to rapid dev
    JavaScript has widespread acceptance, is great in small doses for MVC client-side functionality, and is popular with the college kids. But strongly-typed compiled languages still are much faster to develop.

    One typo in JavaScript and your entire world comes crashing down, without warning until you run the app and test *that exact piece of code*.

    One typo in XAML, and your app wont even compile the second you make the mistake.

    I am in the mid-sized business world, and iterative languages lead to instability and cost about double the person-hours than compiled languages do (dev takes longer, SQA takes longer, maintenance takes longer, product is less stable, etc.)

    If my dev department standardized on JavaScript, we would be out of business by now.

  • Josh Clay

    JS for C# Developers
    Here’s a great link I send to all of my friends who are deciding to finally pick up javascript: http://enterprisejquery.com/2010/10/how-good-c-habits-can-encourage-bad-javascript-habits-part-1/

  • Ben

    Don’t underestimate JS
    For what it’s worth, I was in the same position as many of the JS doubters posting responses on here about a year ago. I had been working almost exclusively in XAML and C#, and I thought Javascript was just for kids and I really wanted no part of it.

    That being said, about a year ago my company decided we were ditching Silverlight (because of Microsoft’s decision to kill it), and switching to an HTML5/Javascript client. Our LOB applications are quite complex, and we have a designer that wants everything to be sexy and APPLE like. After pounding my head against a desk for a week, I decided to go with it and start learning JS.

    Now, after a year of developing an app in it, I must say that my feelings have changed completely. JS is powerful (from a developer point of view), easy to maintain and extend (if you organize your code properly), and just downright great.

    There are great 3rd party libraries you should consider using if you are hesitant about JS and come from a XAML world.

    #1 recommendation is jQuery – makes DOM manipulation simple (you can walk up and down elements just like you did in Silverlight/WPF)

    #2 recommendation would be using KnockoutJS – databinding makes the transition from Silverlight/WPF to HTML5/Javascript amazingly easy.

    Another important item is finding a way to organize and distribute your code so that it is easy to maintain and deliver to the client. After looking at a few solutions (like javascriptMVC and some others), we just decided to roll out our own. This was a boon to our development team. We organized our solution just like one would do for any normal MVVM .NET solution – abstracting out the functional parts of code into separate files.

    Thats enough of me blabbing – just thought you guys needed to hear BOTH sides of the story.

  • kenpofighta

    Well said OJ
    Seems like you have your head on straight even though you are just getting started. I have been doing this for over 15 years now and have done javascript extensively, especially around 2000 when I started using COM eventing and listening for those events in javascript to manipulate the DOM. A precursor to AJAX so to speak. I have personally developed hundreds of thousands of lines in javascript over about a 5 year period and still today write a lot of it. I do this out of necessity and not because the language is so great. The language is abysmal and horrid. Debugging, even with the advances in the IDE, is still horrible. I hate that I have to deal with it at all but it is a must and will remain a must for some time. I love being able to write code in C# with all of the support the IDE provides. It is so much faster to write and so much better to debug. I feel like we have been taken back 15 years in time with javascript and HTML5. I just want to stop and scream sometimes at the direction we are heading. But, I must admit, I embrace change because if I don’t I will eventually be unemployable. It is to that end that I go kicking and screaming along with it.

  • Anonymous

    Ok then, so what tools?

    It so happens that I’ve been working in Javascript a lot recently as well. I’ve been using Dreamweaver (CS4) which is just so so.

    What I would like is an IDE / editor that is jsFiddle like. That is, something on the client side (Windows desktop) that will execute and debug JavaScript code and display output in a separate pane. (No browser required.)

    I commute and frequently work on a notebook and I can’t stand working with a lot of windows open. (Dreamweaver, IE, IE’s debugger)

    So, what’s a really good JavaScript IDE?

  • Anonymous

    Ok then, so what tools?

    It so happens that I’ve been working in Javascript a lot recently as well. I’ve been using Dreamweaver (CS4) which is just so so.

    What I would like is an IDE / editor that is jsFiddle like. That is, something on the client side (Windows desktop) that will execute and debug JavaScript code and display output in a separate pane. (No browser required.)

    I commute and frequently work on a notebook and I can’t stand working with a lot of windows open. (Dreamweaver, IE, IE’s debugger)

    So, what’s a really good JavaScript IDE?

  • Dan Sutton

    Concur!
    @BuggyFunBunny — Brilliant!

  • Anonymous

    Resharper On Visual Studio
    I added the Resharper extension to Visual Studio and it makes JavaScript so much more pleasant to code. It highlights typos, variables that are not used, and has better intellisense. After learning JavaScript patterns and using Resharper, I can easily organize and navigate large code.

  • nickb

    Tools
    @Anonymous: If you’re coming from the C#/.NET stack, stick with VS.NET 2012. There are some more lightweight, slick JS IDEs on MacOS, but on Windows you’re pretty limited. Dreamweaver CS6 (current release) is mediocre at best (which can be said for many Adobe products, but I digress.)

    There’s also IntelliJ IDEA and a variety of Eclipse-based IDEs on Windows that you can try out if you’re willing to leave your comfort zone.

    Re: having lots of windows open… I hate to break it to you, but if you’re doing any sort of web development, I’d suggest getting a second monitor wherever you’re plunking down your laptop. You’ll want to have both code and a browser open and visible at all times if you want to be at all productive.

  • nickb

    Tools cont.
    Also – if you’re debugging JS in IE, you’re doing it the hard way.

    Chrome developer tools or Firefox + Firebug (and Fiddler if you want to get deeper into it) are lightyears better for doing anything JS-related. IE’s dev tools have been a thorn in the of web developers for as long as I can remember.

  • Paul Norman

    Create multi-platform desktop apps…
    And you are nbot just limited to the Microsoft Stack … Paul —

    "Create multi-platform desktop apps
    with HTML5, CSS3 and JavaScript
    TideSDK is the new standard for creating beautiful and unique desktop apps using your web development skills."

    http://www.tidesdk.org/ – Open Source

    You can use either JavaScript or any combinations of JavaScript and or- Php – and or Python and or Ruby

    From their front page…

    First things first. Go ahead and grab the latest stable version of the SDK for your operating system and follow the instructions to set it up. You’re ready to rock!

    TideSDK’s versatility allows you to couple your favorite web technologies with TideSDK’s powerful API to build native cross-platform desktop apps.

    When you’re done. TideSDK will aid you in creating an app package for the operating system of your choosing – say what?

  • Brandon Hunter

    Good Article
    Very please to see another developer embracing JavaScript. I’ve always been a fan of JavaScript and C#, but the one thing that I’ve always noticed and preached to co-workers is JavaScript is much more flexable then C# in terms of executing code on different machines.

    Good Job!!!

  • Mike

    VB C# XAML to js
    Put your head down and you can be pretty competent in 6 weeks.
    I really miss XAML, XML literals, debugging, etc.
    However with jquery and jquery mobile have managed to write a complex app which uses local database storage, gps, camera and communicates with IIS server asynchronously. The app runs offline as well. This all without using phonegap.
    Still think Xaml is better but js is growing on me.

  • mycall

    TypeScript aka ES6
    What’s your view of the TypeScript compiler?

  • joelcochran

    RE: TypeScript aka ES6
    @mycall: I’m a big fan of TypeScript. It’s a great developer tool, helps enforce intent (kind of like contracts), and weeds out dumb mistake, typos, etc. It’s especially good if you have lots of interaction between many JS files. Think of it as a compile-time sanity check.

    In the end, though, you still ship JavaScript, so you still need to understand JavaScript.

  • Dagwood

    Yuck
    Apparently, I have more self-respect than some.
    I would rather go drive a truck than squander my life coding in JavaScript or anything like it.

    "Web development" and it’s associated primitive "tools", along with beasts like Scott McNealy and Larry Ellison, have set software development back generations – not years, generations. What a horribly tragic disaster.

    C#.Net/SQLServer are about the only things that keep my brain from shriveling in revolt and falling out my nose.

  • Joel Job

    Hurl at JS
    I fully agree with Dagwood, OJ and SimplyCoding.

    I cannot imagine creating fast, realiable LOB and easily maintainable and debuggable code in JS. One requires the strong-typed VS.Net IDE which let you step into the lowest level of any controllable code you are writing.

    I would consider a career-change before throwing my coding-standards for a bowl of sh!t with JS.

  • pky

    anonymous lamba yack()
    agree dagwood etc.

    Javascript is good way to keep your in javascript code maintenance business for coming 20 years.

    I myself prefer write code once and don’t debug it with newest browser updates for every week.

    E.q. Jquery, jquery ui & jquery plugins are way too easy to break.

    And code for some of the plugins is main horrible.

    Javascript (also java, c#) basically try to be common lisp without any good parts of common lisp.

    e.q. if browser would use common lisp instead javascript there would not be any need for json, xml etc (as you know, maybe, in common lisp (or lisp) data is exactly like code.

    Sometimes thought about writing backend for my common lisp compiler to produce javascript instead of c (and taking of gc etc etc) but maybe not worthwhile.

    I like c# thought, nowadays , day by day, it reminds common lisp more and more, except horror coding style. No parenthesis (almost) 🙂

    PKY