Hatin' on Javascript, revisited
Or, "Teaching Web Design, part 8.5." This entry is a follow-up to "Hatin' on Javascript." I am posting this entry because I promised that I would correct myself if any Javascript was covered this semester and because I need to clarify some information for readers. Hopefully I can accomplish everything without writing for hours…
First things first: Javascript was covered in Monday's lecture, which was title "Javascript Tricks." The students in the course will not be tested on nor will be expected to know Javascript, it was simply "introduced" to them. Here are the topics that were covered:
document.writeln("...");, even though we teach XHTML 1.0 Strict and document.write* does not work when served asapplication/xhtml+xml.alert("...");window.open("...","","");- Objects in Javascript (even though we never taught them in PHP, and only half the students have (at most) a couple weeks of experience with OOP in Java)… amounting at most to explaining that elements like "window" are objects and that "window.open" is a method that belongs to that object.
- Detecting browsers with
navigator.appname - Events, such as
onMouseOver - Image rollovers (headdesk)
- Dropdown menus
And finally, students were referred to Thau's Javascript Tutorial… not a book, and it's a bit outdated.
Second: It appears that I need to explain the details behind INFO 130: Introduction to Web Design and Programming at Cornell and my involvement in the course. I explained some things before over the course of the past 9 entries I've written on this topic, but I should definitely repeat myself for all the newcomers:
Cornell does not have a web design program; there are no "web design" or "web development" majors here. There is an Information Science major in the Arts and Sciences school and an Information Science & Systems Technology major in the Engineering school, and both cover the same courses. These majors are the only ones at Cornell concerned with web design, but they really aren't concerned with web design at all. The sequence of web design/development courses at Cornell amounts to:
- INFO 130: Introduction to Web Design and Programming (XHTML, CSS, PHP)
- INFO 230: Intermediate Web Design and Programming (PHP, MySQL)
- INFO 330: Advanced Databases (SQL, JSP or ASP)
That's really it. Moreover, there are no professors at Cornell that possess any real expertise in CSS or XHTML; most have computer science backgrounds. To give you an idea, the current INFO 130 professor learned CSS last summer, and while he's commanded it enough to teach it very well (eventually you get so good at computer science that you can pick up just about anything), he doesn't actually know it as well as some of his student instructors. Plus, no one at Cornell is a Javascript expert; this is not my conjecture, this is fact. A few of us students know it well enough to convey the basics, but I know for a fact that none of us could offer an advanced course on it.
So what is the point of INFO 130? Truth be told, the course exists as a "feeder course" to generate interest among students for the Information Science major and encourage them to pursue it. It does not attempt to provide a strong skillset in web design; on the contrary, the best web designers at Cornell are self-taught (myself included). So in short: INFO 130 is just a spring board into the wild, wild world of web design, even if there is no pool to jump into.
Now, about the students: more than half of the students who sign up for our course have no programming experience whatsoever. Seriously. None at all. We have about 110 students in all and with approximately 18 students per section, that leaves each student instructor with two handfuls of students who need to learn the very basic basics of programming, regardless of which language is used. Why are these students taking the course? Well, many are freshman and sophomores who are interested in Information Science or just want to know how to make webpages. Others are majors from other colleges (Communication, for example) who take the course because it is recommended for their field of study. Still others are staff at Cornell who are told to take the course by their bosses. We get all kinds. The course is advertised as "open to anyone who knows how to use a computer," so it's no surprise that less than half have programming experience.
As for the student instructor situation, all student instructors (there are 6 of us in all) are students who took the course at some point and performed very well (A+ even) and are very knowledgeable about the material covered. As the course is being shaped and changed now and in coming years, the student instructors will always have a strong influence on where the course goes and how it is taught; not because we forced it to be that way, but because the professors request it. Besides, some of us know this material better than the professors. When I gave my lecture on C.R.A.P. in design, it wasn't because the professor liked me. It was because none of the professors know the topic as well as I do. Again, I'm not saying this to inflate my ego. I'm being honest.
And the course is gradually changing from year to year. The course is not perfect as it stands now and there are changes that all of us (professor included) would like to see in the future. We are all thinking about how much we should cover in the semester, what technologies to focus on, and how much experience the students should have. It's not easy teaching so many students topics like PHP and CSS while trying to introduce them to core programming concepts they have never seen before. Besides, we are not teaching just one language; even without Javascript, we are covering 3 in depth and expecting all students to understand them well enough to pass the exams. How many languages did you learn in your first semester of programming? If it was more than one, how different were they? I think XHTML, CSS, and PHP are a tough combination, however simple each one might be on its own.
Finally, the course culminates in a final project where students have to work in groups and build real websites for real clients. The goal of the course is to give them everything they need to accomplish that task, and if you can imagine what it's like to take beginners from start to finish where they are capable of building real websites in a matter of 2 and a half months, then you probably understand why all this is blog-worthy.
Back to Javascript
So I made some points a few entries ago about why I didn't like the idea of Javascript being presented in INFO 130. I didn't have to blog about it, but I started this semester intending to share my experiences as a student instructor and I thought it was worth sharing. I can take a little time to qualify those points, but they are not intended to be the crux of this discussion. Here's the last I'll say on this:
- Javascript has to be the worst language I’ve ever seen. I'm referring to syntax here, since that's all you see when staring at the code for hours. I've seen the following programming languages:
- Java
- C
- C++
- Verilog
- PHP
- Variable names have no clear delimiters: This is a variable name with a delimiter:
$item. This is a variable name without one:item. This is an example delimiter:$. I don't have to explain why I prefer delimiters in variable names, but I'll do it anyway: they make code easier to read. In a language that is mixed with HTML and CSS, ease-of-reading is very important. - Javascript just makes me sick: after wrestling with pointers in C all weekend, I take this back. My stomach has a new allergy.
- There are very few rules on how code should be written, and I'm not in a position to make some.
- There is too much outdated code mixed in with proper DOM-scripting. I think Javascript becomes powerful when you use it to manipulate the DOM, but I would prefer a dedicated approach to DOM-scripting over using a language that has DOM-scripting as a feature.
- Javascript is heavy on system resources (in comparison to things which are not). There isn't much one can do to optimize Javascript. The sky is blue. The grass is green. Water is wet.
- I believe that the majority of websites have no need for Javascript. That does not mean that they shouldn't use it, but that they would still be able to serve their purposes without it. If you had to choose between only PHP and only Javascript for building a dynamic website, which would you choose?
And I quote (myself):
[Hatin' on Javascript] isn’t to say that students shouldn’t learn Javascript at all; I would love to teach a full course on Javascript, covering everything from DOM-scripting and progressive enhancement to AJAX and OOP, with a bit on frameworks for good measure. That’s just me and my wishful thinking (I doubt such a thing would ever be possible at Cornell). The truth is that I do love Javascript, and I use it, even in some cases where the justification is questionable. I just want students to get a proper introduction to it, and I don’t want them learning outdated obtrusive practices, ever.
But all of this is my opinion, and it might have been a mistake to present this alongside with my account of the goings-on of INFO 130. If that got under anyone's skin, well, my mistake.
I have a problem set to work on, but in closing: compare my quote with the topics that were covered in the single lecture on Javascript. Keep in mind that almost all the material was way over the heads of the students. Do you think the lecture was worthwhile? Should it have been presented, or should we have focused that time on one of the core topics (XHTML, CSS, PHP, Design, Usability)? I would really like to hear your opinions.
I just have to point out–it's not actually /that/ slow:
http://www.fourmilab.ch/fourmilog/archives/2005-08/000567.html
This is a floating point benchmark, not something you'd want to do in JS anyway. For pretty much anything else–the things you'd normally use JS for–it's pretty fast.
Well I'm not talking about speed, but okay.
I can also reverse the whole thing: how can I address window and document objects without javascript??
I can split performance between client-side and server-side, eg remote scripting?
Correct me if I am wrong?
Johan: All very true, but I'm certain that the concepts you are addressing are far too advanced for our group of students. Keep in mind that the majority of them have little or no programming experience!
I'm afraid that one of the reasons that your previous post 'caused some controversy' is that you are mixing up loads of different things at the same time, and still passing off personal preference as some sort of factual certainty. I have 'seen' all of the languages that you quote above, and a few more - Pascal, Cobol, VB, PERL - and I would have to say that only Java is nicer to read than Javascript, and none of those was easier for me to work with. However it is generally recognised that the main reason that people like or dislike languages is whether they are like what they have been brought up on. Javascript is intended to be similar to Java, which can be a real pain occasionally when the two differ in syntax, but is nice most of the time (if that is what you usually use.) NB Java doesn't do silly $variable stuff - is that a bad language too? In my opinion, there is nothing worse for someone unused to PERL than having to understand that $var and @var are the same thing sometimes, and different at other times.
On a different level, I understand why you say that Javascript is slow, but you are wrong. Most Javascript is run in an interpreter embedded within a browser - this gives it loads of overhead, but VBScript doesn't run any faster, and server-side javascript can be faster than Java, since it is so lightweight. This is not a language problem, it is an environment issue.
I don't know why you complain that people on the WSG mailing list haven't supported you - we both know how much 'discussion' can occur from relatively simple things on the list - I doubt this would have been any quieter if you had posted this there directly.
Funny, I'm just watching this fancy Javascript "Live Preview" as I write this comment slowing me down
I feel empathise with your situation Christian! I'm facilitating a Web Design certificate which similarly takes a "no programming experience necessary" requirement and expects dynamic sites with Javascript , PHP/MySQL, DOM scripting etc out the other end.
I don't think the people setting the requirements understand the amount of learning required for programming. Sure, a few people pick it up and run, but most need lots of time, examples, activities, and the luxury of learning and applying skills at a suitable pace (often meaning individual pace).
Our approach has been to provide our learners with lots of hands-on activities (learning by doing). We try to make the activities as practical and immediately useful as possible.
Take a look at the Javascript Challenges (and feel free to use them, or invite your students to improve them!).
You might notice (and complain!) that Unobtrusive Javascript is the last challenge (Challenge 7). But I think it's important to get learners started with something practical and achievable without overloading the brain… Without any experience in programming, I think it is possible to understand what <p onmouseover="window.alert('Hi there');"> …</p> is doing, apply it over and over, and learn about events at the same time… (which is why we have Getting to know your window, and Getting to know your document to start people of before the more useful JS Challenges)
But to start with the unobtrusive version would, I reckon, be brain overload, confusion, not encouraging, not transferable etc., unless you had a background in programming and understood functions, events etc.
Anyway, hope that's helpful!
BTW: ah, du sprichts auch Deutsch? Und wolltest auch in Deutschland (oder Europa) arbeiten… kommisch. Mein ehefrau ist Deutsche… wir wollten unserer kinder beide Sprache haben, so jetzt lerne ich auch
Ich finde deiser TopThema Podcast ganz hilfreich (hilflich? helpful)
Cheers, Michael
Mike: On the subject of support, I just didn't like that some were saying that the link "didn't belong in their e-mail" and were questioning my knowledge.
Also, I never said Javascript is slow. You can go back and read what I said. I said that Javascript is resource-heavy, which means it can take up a lot of memory. That's completely different from how much speed it uses, and I think it's a valid statement. But I'm just a hypocrite until I replace this "Live Preview" function with something better.
Michael: That's the biggest problem; most of the students do not understand functions or events. We had to teach them how to write functions with PHP but a lot of them still don't know how. At least if they were all intending to pursue web design as a career, then they would probably pick the stuff up faster, but many of them are just their to pick up an extra skill on the side, and it's hard to make the class intense without losing them completely.
Und ja, hilfreich. Danke für der Link.
Well I'm not the only one to interpret what you said as meaing that JS is slow. Either way, the implementation is not directly linked to the language - JS is sometimes used on the server side, precisely because it is a light-weight language - that is how it was designed, and I don't mean in terms of features.
Despite the prevalance of Internet Exploder, VBScript in the browser simply never took off, so it is hard to believe that VBScript is better than JS. Any comment on the miriad other points that have been made, or is it enough to throw up a single argument against everyone?
Finally, if you are dead set against JavaScript, and the students are not facing an exam, then just teach them about the bad things - show them how JS can be used to make a page in-accessible, and leave the positive stuff for another day and another teacher.
No, no other comments from here
I see what you mean about teaching the perils of Javascript, and I only wish I could! But sadly, tomorrow is my last day of teaching, and the agenda for that 50-minute section is already full.
Christian said:
Yep, I have this same problem. What I'm trying to say is, I think it's possible for people to learn about events (and have fun doing it - eg: Getting to know your window) and even begin to see the need for functions without the added complexity of unobtrusive JS (which has a much greater assumed knowledge).
I don't think it's necessarily bad to learn JS like this. Same when I start people on HTML - I don't get them to use DOCTYPES on the first day, although as soon as they've created their first page we add it and see why it's so helpful. Just a matter of breaking things up into consumable chunks.
Michael: Thanks, I never looked at it that way. I'll keep that in mind.
Christian you are fully entitled to your opinion. Personally I find javascript a useful, powerful, and elegant language. Given the syntactic resemblance between javascript and c, c++, java I fail to see how javascript is syntactically the worst.
A random sample of websites is unlikely to procure even one that is using javascript appropriately. This isn't a problem with the language, it is a problem with the programmer. Programmer problems are inherent in most software, however only javascript gets distributed as source code with each webpage making it easy to separate newbies from adepts.
There absolutely are ways to optimise javascript as there are ways to optimise any language (Speed Up Your Site by Andrew B. King is a great resource for web site and javascript optimisation techniques). The rules for writing good javascript are no different to writing good code in any other language, I would highly recommend Code Complete by Steve McConnell for practical advice on software construction.
The resource that really opened my eyes to javascript was David Flanagan's JavaScript The Definitive Guide. This book should probably be on every serious javascript developer's desk.
A choice between javascript and php for dynamic websites, hardly a fair comparison. I think they are perhaps complementary.
Information Science is offered by CALS (College of Agriculture and Life Science) too… don't hate.
Wow Cam, they copy everyone huh?
OK, correction, IS in Arts & Sciences, IS in CALS, and ISST in Engineering. Done.
This is only partially true; its not required that variables have a $ character prefixed. However, you'll struggle to find an implementation that wont let you use them[1]. So if you really want them they you are certainly able to use them.
However I personally think you are better of replacing your text editor with something that better colorizes javascript if you are finding this to be a problem.
[1] I am aware that offically they are only supposed to be used for machine generated code, but really that is a minor sin compared to most JS code.
Actually Andrew, my reason for wanting delimiters in Javascript has nothing to do with editing; it is because when viewing Javascript source embedded or alongside HTML, CSS, and sometimes even PHP, it's nice to have variables very clearly delimited. This is why it's a good thing that PHP variables require the $; seeing plain-text variable names in source-view is just not ideal.
But what can ya do?
But as you yourself pointed out before - in this day and age we should be using unobtrusive Javascript and external JS files, so this situation should not occur with decent code. In any case, only in PHP (etc.) do you have any chance of JS appearing without the necessary identifying wrappers.
I figured I should post considering I kicked up such a stink in the comments of the other article. Mike has touched on the fact that you seem to be unable to answer any of the questions asked in either article. You've responded by stating that you're not going to comment on any of the said questions, so it's futile to attempt to take the discussion any further.
Personally, I think you should turn off comments for your blog if you're not interested in listening to opposing points of view and responding to them.
I also suggest that you learn about:
Nathan: You would be the only one that feels that way. At this point I am in agreement with the things Mike said and I've learned things from him and some of the other commenters. Everyone besides you has been able to discuss things coherently without making dirty personal attacks, and with the exception of you, the discussion has been very fruitful. You are free to get with the program whenever you like, but as long as you don't I will just have to disregard your comments.
Comments remain open on this blog for the 100 or so other users that enjoy them.
Well this is getting old but since you're still posting inaccurate comments I still feel compelled to respond. I am in total agreement with Nathan. Your knowledge of javascript is obviously meagre. You make sweeping and inaccurate comments about javascript and when someone has the temerity to point out your errors in both fact and logic you cry foul. Your definition of fruitful is accurate only insofar as it refers to those who agree with you, which should more correctly be referred to as a love-in. I'm also going to assume that in reference to disregarding Nathan's comments you in fact mean discard. Consider this a dirty personal attack if it makes you feel better.
Thank you for the enjoyable afternoon reading. I commend Dave and Nathan for their attempts, possibly in vain, to better equip you to teach the language you 'love to teach'.
Dave: You are really good at these passive-aggressive "safe" comments where I can't argue with anything you say. According to you, you are right because:
Is there anything legitimate about your comment? Does it have anything to do with the original entry? Have you touched upon any of the statements I have made in this entry? Did you even notice where I changed some of my evaluations of Javascript?
Discarding Nathan's comment would mean deleting it, but I don't do that because I believe in leaving comments up for everyone to see. I will likewise leave your comment up too. Now if you have to be defensive about it and assume I will regard it as a "dirty personal attack," maybe it is not because I do it to "make myself feel better," but because it is a "dirty personal attack." I mean, if it smells like it, looks like it, and feels like it, it probably is, right? It isn't like I don't know Javascript, so both you and Nathan are already wrong big time… that makes you stubborn or just plain immature.
Now I could just disregard your comment like I will Nathan's, at least until the two of you come back and make the same point respectfully, but I will take this opportunity to at least try to bring some good about this by teaching you (and possibly Nathan) about how to have discussions like mature adults. It's a really simple bit of advice, actually: when having a discussion with someone who you are in disagreement with, do not make assumptions about their level of knowledge. That is both off-topic and considered a personal attack, and serves only to anger the opposite party as well as distract from the original argument.
Josh: My job has never been, and still isn't, to teach Javascript. My job this semester was to teach PHP, XHTML, CSS, accessibility, usability, and visual design. My job next semester, if I get the opportunity, is to teach MySQL and more PHP. The only thing Dave and Nathan accomplished was a (possibly amusing) round of lousy comments.
OK, I'll bite one more time and I'll endeavour to stay on the topic. You expressed some strong opinions and made a number of inaccurate comments about javascript. Putting your comments on the web was inevitably going to engender a strong response. Nathan's response was robust but not ill-considered. Your reaction however was a little juvenile ("You are wrong on all counts", "My points are not opinionated", and shouting is rarely an appropriate response).
Moving on to your more recent post.
Javascript syntax is very similar to Java, C, C++ all of which you've seen. I fail to see how it is worse and you don't provide specifics.
Personally I find decorators on variable names make code more difficult to read. Using an editor that provides syntax colouring can make a huge difference and keeping javascript and css out of your html is good practice.
There are rules and breaking them will cause your application to break. Javascript's official name is ECMAScript and is standardised in the ECMA-262 specification. Different browsers have differing levels of support for the standard in much the same way there are different levels of support for css.
Javascript was originally developed to put the D in DHTML.
I'll ignore the absurdity of your parenthesised comment. Resource usage depends on a variety of factors including which browser you are using and what the application is trying to do. There are in fact many ways to optimise javascript and I mentioned previously a good book that covers some optimisation techniques.
Developing dynamic websites is not about choosing between a client-side and server-side language. It's about using what is appropriate for the site you're developing. Ecommerce sites rely on server-side technology, frequently with little consideration for the client-side experience. The likes of GMail have a hefty dependence on client-side javascript.
Actually resources are not limited to memory; if you meant to say javascript uses a lot of memory you should have said javascript uses a lot of memory. Resources do in fact include disk space, memory, processor, etc.
Actually there is a great deal I don't know about javascript. As with any useful tool, mastery requires practice and a willingness to learn. My impression of your knowledge/ability with respect to javascript is based on your posts. Frankly and without malice, your javascript knowledge appears a little light.
Dave: Wow, that was much better.
First, I think decorators are just going to be a matter of personal opinion. They seemed nice when we were teaching PHP.
Second, Javascript is not ECMAScript, it is an extension of the ECMAScript standard, meaning that it includes things that are not defined in the ECMAScript standard. From Wikipedia:
Basically, ECMAScript is DOM-scripting and a lot of the Javascript that I don't like to see (like
javascript:links anddocument.writeare not ECMAScript, but features unique to Javascript. JScript, Actionscript, and a handful of other languages are all extensions of ECMAScript, but like I said, it would be nice to have a language without extended features. I'll admit, however, that Javascript has the best features of any ECMAScript implementation and I love the frameworks available and the ability to make requests withXMLHttpRequest.Third, none of the students at level 1 web programming at Cornell are going to be writing Gmail any time soon. Also, Gmail is loaded with messy Javascript and throws errors every 5 seconds. I would love to be able to write an app like Gmail but I would also like to see it written with proper DOMscripting and not the mess that it is now.
Fourth, if your code goes off into disk space you definitely have a problem… but that's neither here nor there.
Fifth, if anything, it can't be too much lighter than yours… but this isn't a pissing contest.
Otherwise, I agree with your comments. I am allowed to change my mind on occasion, right? Now you never did answer my original question… looking back on the topics covered up there, would you have taught those specific ones? Or would you have covered something else?