You Have Nothing To Fear From Javascript

Building a web application consists of a number of discrete layers: server code, client code, HTML, and styling. If you cannot sit down with one of those layers and work on it, you are not fulfilling your role. If I hire a web developer, I don’t expect them to tell me that they know little of Javascript, but unfortunately there seems to be a fear of that language, where people are happy to hide it away behind a facade of server-side code which autogenerates it.

This is wrong. If you are working with Javascript, client side code, then you should be able to fully debug, understand, and tweak that code natively. Changing some C# code which you think will generate the right JS is such a horrific approach I can’t believe anyone would advocate it. In order to have a robust application you need full control of all aspect, from top to bottom.

Besides, Javascript is actually a great language, though much maligned over the years. As the web matured, Javascript was often responsible for scrolling banners, page errors, and other affronts to the user. But as people have documented its browser support and language tricks, Javascript has matured with its environment. Check out this structure in Javascript:

// Setup "static" structure<br>var Application = function() {<br><br>	var _privateVar = 0; <br><br><br>	return {<br><br>		someFunction : function() {<br>			_privateVar = 5;<br><br>		}<br><br>	}<br>    } <br>}();<br><br>// Run the function<br>Application.someFunction();

Organised, readable Javascript! Whatever next! You can even have psuedo-namespaces, classes, anonymous functions, loads of great dynamic language features which allow you to come up with flexible and concise code. Generating your JS isn’t just unwise, it means you’re missing out on all the fun!

This entry was posted in javascript. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

9 Responses to You Have Nothing To Fear From Javascript

  1. Troy Tuttle says:

    Interesting post. I don’t know if it is fear of Javascript that dissuades people from using it, or a desire to be pragmatic. I admit that Javascript is more important now, in a “Web 2.0″ and ajax world.

    But we could really apply your same logic to the database layer. If you, as a application developer, propose using an ORM or code generation tool for the data access layer, then you really aren’t fulfilling your role as an application developer. You shouldn’t hide the database away behind a fa├žade.

    I think a lot of developers see (correctly) that data access code is ultimately just plumbing code. Many see Javascript as the same, just plumbing code to wire your app up with external implementation details.

  2. cramsay says:

    I understand the attitude, but javascript is not plumbing code, in the same way that CSS is not. What you do in your JS has a fundamental effect on the user experience, and is unique to each application.

  3. joeyDotNet says:

    Funny you should post this now. I’ve been doing some interesting stuff with OO javascript lately and thought about posting something about it. I agree, I’m starting to find javascript to be a pretty nice language. I do have to say that frameworks like prototype make it much more “fun” to use.

    Hmm, I may have another post in the works…

  4. lol

    It is funny indeed that you posted about this. I was getting ready to compose a post on the different javascript frameworks available. I want to start doing alot more dynamic stuff on the UI and with web apps the next logical step is start to use mroe javascript. The options of frameworks out there though are dizzying.

    Good post Colin!

  5. Sergio Pereira says:

    JS is probably the most misunderstood language out there. The C-like syntax and the java in it’s name are probably the biggest problems. Developers think they know JS just because of the familiar syntax.

  6. Troy Tuttle says:

    I agree that javascript has a fundamental effect on the user experience. But that doesn’t mean it isn’t effectively plumbing code. As you can probably tell, I have a very broad definition of “plumbing code.” I view anything as plumbing code that doesn’t contain proprietary domain logic.

    An HTML element is an HTML element, just as a database table is a database table. I shouldn’t be writing code by hand to manipulate either.

    Here is my approach:
    The concern of my domain layer is to make domain or business decisions on the data. The concern of my data access layer is to store and retrieve data. The concern of my UI layer is to display my data. Maybe plumbing is the wrong term, but the only layer that has to be written mostly by me is the domain layer. The other two can be developed with the assistance of tools.

    If you are doing something that is truly unique/proprietary in your business web site, it should exist in your domain layer. If you put that in the web UI, it will soon not be unique/proprietary since you will be shipping that code to any browser that requests it.

    Just my two cents…

  7. cramsay says:

    “Maybe plumbing is the wrong term, but the only layer that has to be written mostly by me is the domain layer. The other two can be developed with the assistance of tools.”

    This is an even stranger approach to the issue, IMO. If you are designing a full web application, you need to concern yourself with *detail* from top to bottom. If you’re specifically just coding the domain model and have others to do the user interface, then that’s ok, but you should still have an awareness.

    Your approach is like building the engine for a car and then having a tool design the dashboard, controls and body shape based on the capabilities of the engine.

  8. Troy Tuttle says:

    I don’t disagree that attention to detail and design work is needed in all layers. UI’s must be designed by someone (maybe yourself) that understands graphic design and usability. Databases must be designed by someone who at least minimally understands relational database theory. I’m not saying ignore the detail at the design level.

    Let’s take a specific example: A web page must restrict content/data based on a user’s role. The logic to declare and determine user roles must reside in the domain layer, correct? The UI’s main responsibility is to carry out (display) that decision made in the domain layer. If you use javascript and css to assist with that, great.

    My main concerns usually stem from experience with developers that decide to implement something like a distributor cap in their dashboard, just because their tools have that capability. So when I hear people get excited about the capabilities of Javascript, TSQL, or any language used outside the domain layer, my domain modeling red flags usually go up.

    I appreciate the discussion.

  9. I can’t say I fully agree with you.

    I think there are many opportunities for js generation that allow you to be very productive, and have your javascript guru write and have everyone use.

    I do not see any value in trying to fully hide the language however.

    And nothing of course absolves you of the responsibility of having to know what is going on underneath. I’m just saying you should be able to program at a higher level most of the time and not worry about nuts and bolts.